About Microservices.io

Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action and the creator of the original CloudFoundry.com. His latest startup is eventuate.io, a microservices application platform.


Learn more about microservices

Chris offers a comprehensive set of resources for learning about microservices including articles, an O'Reilly training video, and example code. Learn more


Microservices consulting and training

Chris offers a comprehensive consulting services, workshops and hands on training classes to help you use microservices effectively. Get advice


Example microservices applications

Want to see an example? Check out Chris Richardson's example applications. See code


Get the book: Microservice patterns


Signup for the newsletter

A new microservices application platform that solves distributed data management problems.

Join the microservices google group

Pattern: Saga

Context

You have applied the Database per Service pattern. Each service has its own database. Some business transactions, however, span multiple service so you need a mechanism to ensure data consistency across services. For example, lets imagine that you are building an e-commerce store where customers have a credit limit. The application must ensure that a new order will not exceed the customer’s credit limit. Since Orders and Customers are in different databases the application cannot simply use a local ACID transaction.

Problem

How to maintain data consistency across services?

Forces

  • 2PC is not an option

Solution

Implement each business transaction that spans multiple services as a saga. A saga is a sequence of local transactions. Each local transaction updates the database and publishes a message or event to trigger the next local transaction in the saga. If a local transaction fails because it violates a business rule then the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.

Example

An e-commerce application that uses this approach would create an order using a saga that consists of the following local transactions:

  1. The Order Service creates an Order in a pending state
  2. The Customer Service attempts to reserve credit for that Order.
  3. The Order Service changes the state of the order to either approved or cancelled

Each local transaction publishes an event or message that triggers the next step. For example, in the CreateOrder saga, the OrderService publishes an OrderCreated event and the Customer Service publishes either a Credit Reserved event or a CreditLimitExceeded event.

Resulting context

This pattern has the following benefits:

  • It enables an application to maintain data consistency across multiple services without using distributed transactions

This solution has the following drawbacks:

  • The programming model is more complex. For example, a developer must design compensating transactions that explicitly undo changes made earlier in a saga.

There are also the following issues to address:

  • In order to be reliable, a service must atomically update its database and publish an event. It cannot use the traditional mechanism of a distributed transaction that spans the database and the message broker. Instead, it must use one of the patterns listed below.

See also

The article Event-Driven Data Management for Microservices by @crichardson describes this pattern


Copyright © 2017 Chris Richardson • All rights reserved • Supported by Kong.