Saga

Tldr

The Saga design pattern is a way to manage data consistency across microservices in distributed transaction scenarios. A saga is a sequence of transactions that updates each service and publishes a message or event to trigger the next transaction step. If a step fails, the saga executes compensating transactions that counteract the preceding transactions.

How Saga functions?

The Saga pattern provides transaction management using a sequence of local transactions. A local transaction is the atomic work effort performed by a saga participant. 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, the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.

Example of Saga

In this example, the 2 related steps of book hotel, book flight, and book rental car must all be successful to book a trip.

The first step in the overall transaction is to book the hotel. If that task is successful, then the BookFlight task is executed. If that task is successful, then the BookRental task is executed.

But what if one of the tasks fails? For example, if the BookFlight task is not successful, then the CancelFlight task executes, followed by the CancelHotel task to reverse the transaction. Likewise, any failures with the BookRental task would lead to the CancelRental task, which then initiates the CancelFlight task, which then executes the CancelHotel task.

Flight booking Saga Example

When to use Saga?

Use the Saga pattern when you need to:

• Ensure data consistency in a distributed system without tight coupling.
• Roll back or compensate if one of the operations in the sequence fails.

The Saga pattern is less suitable for:

• Tightly coupled transactions.
• Compensating transactions that occur in earlier participants.
• Cyclic dependencies.

Orchestration based Saga

1. The saga orchestrator sends a Verify Consumer command to Consumer Service.
2. Consumer Service replies with a Consumer Verified message.
3. The saga orchestrator sends a Create Ticket command to Kitchen Service.
4. Kitchen Service replies with a Ticket Created message.
5. The saga orchestrator sends an Authorize Card message to Accounting Service.
6. Accounting Service replies with a Card Authorized message.≠
7. The saga orchestrator sends an Approve Ticket command to Kitchen Service.
8. The saga orchestrator sends an Approve Order command to Order Service.

Choreo based Saga

1. Order Service creates an Order in the APPROVAL_PENDING state and publishes an OrderCreated event.
2. Consumer Service consumes the OrderCreated event, verifies that the con- sumer can place the order, and publishes a ConsumerVerified event.
3. Kitchen Service consumes the OrderCreated event, validates the Order, cre- ates a Ticket in a CREATE_PENDING state, and publishes the TicketCreated event.
4. Accounting Service consumes the OrderCreated event and creates a Credit- CardAuthorization in a PENDING state.
5. Accounting Service consumes the TicketCreated and ConsumerVerified events, charges the consumer’s credit card, and publishes the CreditCard-Authorized event.
6. Kitchen Service consumes the CreditCardAuthorized event and changes the state of the Ticket to AWAITING_ACCEPTANCE.
7. Order Service receives the CreditCardAuthorized events, changes the state of the Order to APPROVED, and publishes an OrderApproved event.

---

Was this page helpful?

Yes No