SAGA Design Pattern

Saga is a design pattern that decomposes a long-lived transaction into a series of smaller transactions distributed across multiple services. This design pattern guarantees that either all transactions are successfully completed or runs compensating transactions which rollbacks the previous transactions to its original state.

Problem:

In a Microservices architecture, the Saga design pattern addresses the problem of managing distributed transactions. In a Monolithic architecture, transactions are ACID (Atomicity, Consistency, Isolation, Durability) transactions as these transactions are local to a particular database. Whereas in a Microservices architecture, it is challenging to implement as different services have their own databases and there is no single point of control.

How Saga Design Pattern Works:

The Saga design pattern manages transactions using a series of local transactions. Each local transaction updates the database and publishes an event to trigger the next local transaction. If a local transaction fails, Saga runs a compensating transaction that rollbacks the previous local transactions. There are 2 ways to implement Saga.

Choreograph

Orchestration

Let's look at each approach and their pros and cons.?

Choreography:

Choreography is Event based. Each local transaction publishes events that trigger local transactions in other services. There is no centralized point of control.?

Service A executes a transaction and publishes an event. Service B listens to the event from Service A and performs its transaction and then publishes an event after its transaction. Service C listens to the event from Service B and performs its transaction.?

This continues until all services have successfully completed their transactions. If an error occurs, each service listens for a compensating event and rollbacks the previous transaction to its original state.

Pros:

Ideal for simple workflows with less number of participating services.

No single point of failure, as there is no centralized orchestrator.

Services communicate through events, leading to non-blocking interactions and improving performance.

Cons:

As the number of participating services increase, it is difficult to manage complex event flows.

Integration testing will be difficult, because all services must be running to simulate a transaction.?

There is a risk of cyclic dependency, as every service will consume each other's events.?

Orchestration:?

Orchestration is command based. A centralized orchestrator is responsible for sending commands to services to perform their local transactions or run compensation transactions.?

The Orchestrator starts the Saga and invokes Service A. Service A performs its transaction and replies back to the Orchestrator. The Orchestrator then invokes Service B and service B performs its transaction and replies back. The Orchestrator then invokes Service C and service C performs its transaction and replies back.

The process continues until all services have completed their transactions. If an error occurs, the Orchestrator sends compensating commands to the services to rollback the previous transaction to its original state.

Pros:

Ideal for complex workflows, as the Orchestrator manages the sequence of steps, making it easier to coordinate complex transactions.

No Cyclic dependencies, as the centralized control simplifies the process of testing and debugging.

Participating services can focus solely on business logic, and don’t need to know about commands for other participants.

Cons:

Extra service needs to be implemented for Orchestrator?

Single point of failure, if the Orchestrator fails, it can halt the entire Saga process.?

Use Cases:

Saga is a powerful design pattern in Microservices architecture and could be used in E-commerce (orders, payments, inventory, shipment services), Banking (Money transfers, balance updates, notifications services), Booking Systems (Bookings, payments, notifications systems)