Microservices | Design Pattern: Saga
Microservices based system is a distributed system which consists of small services serving their own different purposes to support the application. Although Microservices based system have many benefits like flexibility to choose different programming language, different database and many more. As usual, good things comes with bad things, just like that Microservices comes with a challenge of handling the transactions.
To handle the transactions in between Microservices, there are many design patterns, strategies. Here we are discussing one of the design pattern: Saga design pattern.
Saga Design Pattern
Saga can be defined as a series or sequence of transactions that updates the local service and trigger the next step in transaction. The Saga design pattern is about handling Saga’s. The Saga design pattern provides transaction management using a series of local transactions, where a local transaction is a piece of work performed by a saga participant(simply, a service).
Every action that is performed under Saga can be rolled back using compensating transaction. Saga design pattern ensures that all operations in a transaction should be completed or none of them should persist. Hence, if any of step fails in a transaction, compensating transaction needs to be executed to roll back the earlier steps done in a transaction. The rule about the compensating transaction is, it should be idempotent and retryable.
- Saga Execution Coordinator
Saga Execution Coordinator(SEC) is responsible to manage all of the steps in transactions and execute compensating transaction too. And, how does it do that? It does it with the help of Saga log. Lets have a look over it while digging into the types of Saga pattern with the example of E-Commerce web, where there are three microservices to perform underlying operations- check stock, complete payment, place order.
- Saga Design pattern is of two types-
1. Choreography
2. Orchestrator
Lets have a look on Choreography first-
- Choreography Pattern
In above diagram, three microservices are involved to complete the flow of placing an order, every service has been implemented with Saga Framework. Saga Executer Coordinator can be embedded in the services or it can be a standalone service also. Every service shown in diagram triggers an event as soon as local transaction is failed or succeeds. The triggered event will be processed in the next service in line as configured. Above is the flow in which the transaction is completed successful.
Above diagram shows the example of failed transaction in choreography pattern. All three services are participants of Saga but transaction failed at Payment service, hence, the whole transaction gets failed without even reaching to Order service and in order to rollback the work done at Stock service, SEC will initiate the compensating transaction.
Choreography pattern can be implemented in Spring boot applications using Axon Saga framework.
Choreography pattern is not the ideal pattern to implement if too many services are involved in a transaction as this service is based on the event received from other services, hence, it can result into cyclic dependency of events.
- Orchestrator Pattern
In Orchestrator Pattern, usually a new service is created which will be responsible to call the Saga participant services in a defined order. Hence, services won’t be dependent on each other’s success or failure events, rather, an orchestrator service will be responsible to call and manage the response of services.
If any of the service responds with failure, then Saga Order Orchestrator will be responsible to trigger the compensating transactions to undo the work done in previous service for same transactions.
This was all about the Saga design pattern, its types and the way of implementing it in architecture.
