Different Types of Saga Pattern

_{^{Image by rawpixel.com}}

In previous blog, we looked into how Saga pattern help us in achieving data consistency across microservices architecture based application. In this blog, we will look into different types of Sagas, their pros and cons. 

Types of Saga Pattern 

There are two types of Sagas

1. Orchestration-based Saga
2. Choreography-based Saga

1. Orchestration-based Saga 

In Orchestration based Saga Pattern, there is central coordinator (Saga Manager or Orchestrator) is responsible for Saga sequencing and business logic execution. Saga Manager send the message and event to the services and listen to services response to decides the next transaction that need to be executed. 

Saga manager will send a transaction request to Service A and listen to the response. Base on response of A it decides which next transaction needs to be executed. Accordingly, it will send event/message to next service to execute the transaction. In case transaction failed in middle of Saga execution, Saga Manager is responsible execution of the compensating transaction and it will send event/message to service to execute the compensating transactions. 

Pros 

1. Saga participant services doesn’t need to know about the command or messages to be sent to other services. Services will have clear business logic implementation without additional overhead. 

2. Good for complex architecture and applications where new services can be introduced over the period of time. 

3. Easy to understand and manage since business logic sequence is manage by Saga manager and there is clear separation of concerns. 

Cons 

1. Saga Manager/Orchestrator can be single point of failure. 

2. Choreography-based Saga 

In Choreography based Saga there is no central coordinator. Each services publishes the event/message for other services that needs to be executed next. 

If a local transaction failed then the service will publish event/message for the preceding service to execute the compensating transactions. 

Pros 

1. Good for simple application where there are few participants. 

2. There is no single point of failure as it doesn’t require an orchestrator. 

Cons 

1. Implementation of complex logic with large number of participants could be confusing. 

2. In the complex application, there is risk of introduction of cyclic dependency. 

Conclusion 

We can choose between Orchestration and Choreography pattern depending on the application needs. For complex applications, orchestration based Saga would be beneficial. Even though it requires development and maintenance of additional services. It helps us in implementing clear separation of concerns. For applications, which have fewer services and simple business logic Choreography based sagas help us in saving cost of maintaining orchestrator. 

Thanks