Managing data consistency in a microservice architecture using Sagas part 2 - coordinating sagas

sagas   transaction management  

---

---

This is the second in a series of posts that expands on my recent MicroCPH talk on Managing data consistency in a microservice architecture using Sagas (slides, video).

The other posts in this series are:

• Part 1 - Overview of sagas
• Part 3 - Choreography-based sagas
• Part 4 - Orchestration-based sagas

In part 1, I introduced the concept of a saga. I also described the Customers and Orders example, which uses a saga to create an Order. In this post I’m going to describe how to coordinate sagas.

Coordinating sagas

As I described in part 1, a saga consists of a sequence of steps. Each step is a local transaction in a participating service. For example, the happy path for the Create Order saga is as follows:

1. Order Service : createPendingOrder()
2. Customer Service : reserveCredit()
3. Order Service : approveOrder()

Similarly, the flow when there is insufficient credit is as follows:

1. Order Service : createPendingOrder()
2. Customer Service : reserveCredit()
3. Order Service : rejectOrder()

The services must implement a coordination mechanism that decides the sequencing of the steps and triggers their execution.

Choreography vs. Orchestration

There are two main ways to coordinate sagas: choreography and orchestration. The two approaches differ in the nature of the asynchronous communication and whether coordination is centralized or distributed.

Choreography is an event-driven approach. When using choreography, there isn’t a central coordinator telling the saga participants what to do. Instead, the saga participants subscribe to each other’s events and respond accordingly. When a service updates its data, it simply emits a domain event announcing what it has done. Other services subscribe to those events, which trigger updates that emit additional events. For example, in the Create Order saga, the Order Service emits an OrderCreated event, which causes the Customer Service to attempt to reserve credit. In a later blog post, I’ll describe how to implement the Create Order saga using choreography in more detail.

Orchestration uses a saga orchestrator that tells the saga participants what to do. The saga orchestrator communicates with the participants using request/asynchronous response-style interaction. To execute a saga step, it sends a command message to a participant telling it what operation to perform. After the saga participant has performed the operation, it sends a reply message to the orchestrator. The orchestrator then processes the reply message and determines which saga step to perform next. For example, the Create Order saga orchestrator sends a Reserve Credit command to the Customer Service, which then attempts to reserve credit. In a later blog post, I’ll describe how to implement the Create Order saga using orchestration in more detail.

Saga participants communicate asynchronously using a message broker

As you have just seen, saga participants communicate using asynchronous messaging: either events or asynchronous request/response.

In order for the communication to be reliable, it’s essential that the saga participants use a message broker that guarantees at-least-once delivery and has durable subscriptions. That’s because at-least-once delivery and durable subscriptions ensure that a saga completes even if a participant is temporarily unavailable. A message will sit in the message broker’s channel (e.g. queue or topic) until the participant is able to successfully process it.

How saga participants atomically update the database and send a message

Each step of saga updates a database (e.g. a business object or saga orchestrator) and sends a message/event. These two actions must be done atomically in order to avoid data inconsistencies and bugs. For example, if a service sent a message after committing the database transaction there is a risk of it crashing before sending. Similarly, if a service sends a message in the middle of a database transaction there is a risk that the transaction will be rolled back. In both scenarios, the application is left in an inconsistent state.

In order to avoid this problem, a saga must use one of the following patterns:

• Transactional Outbox pattern - publish a message by inserting it into an OUTBOX table as part of the database transaction. A separate process (e.g. the Eventuate CDC) retrieves the message from the OUTBOX table and sends it to the message broker.
• Event Sourcing pattern - uses events to persist domain objects and thereby combines updating the database and publishing events into a single, inherently atomic operation.

In later blog posts, I’ll describe how to implement the Create Order saga using choreography and orchestration.

To learn more

• Look at the example code
  • Choreography-based saga version of Customers and Orders.
  • Orchestration-based saga version of Customers and Orders.
• Read my Microservices patterns book, which has a comprehensive discussion of sagas including the trade-offs of choreography vs. orchestration.
• Read or watch MicroCPH talk on Managing data consistency in a microservice architecture using Sagas (slides, video)
• Talk to me about my microservices consulting and training services.
• Learn more about microservices at adopt.microservices.io