Saga Pattern for Distributed Transaction Management in Microservices

One of the benefits of microservice architecture is that we can choose the technology stack per service. For instance, we can decide to use a relational database for service A and a NoSQL database for service B.
This model lets the service manage domain data independently on a data store that best suits its data types and schema. Further, it also lets the service scale its data stores on demand and insulates it from the failures of other services.
However, at times a transaction can span across multiple services, and ensuring data consistency across the service database is a challenge.

Implement each business transaction that spans multiple services as a saga. A saga is a sequence of local transactions. 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 because it violates a business rule then the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.

There are two ways of coordinating sagas:

• Choreography - Event-Based (Message Broker)
• Orchestration - Command-Based (Service Provider)

Choreography-based saga

1. The Order Service receives the POST /orders request and creates an Order in a PENDING state
2. Then Order Service publishes an event to the message broker that an ORDER_CREATED to Payment Service.
3. The Payment Service got the ORDER_CREATED event and does the necessary updates and publishes the event to Order and Restaurant Service that an ORDER_PAID.
4. The Order and Restaurant Service got the ORDER_PAID event and do the necessary updates.
5. The Restaurant Service publishes the event to Order and Delivery Service that an ORDER_PREPARED.
6. The Order and Delivery Service got the ORDER_PREPARED event and do the necessary updates.
7. Finally, Delivery Service publishes the event to Order Service that ORDER_DELIVERED to the Order Service, and the Order state changed from PENDING to COMPLETE.

Orchestration-based saga

1. The Order Service receives the POST /orders request and creates an Order in a PENDING state
2. Then Order Service sends the command to Orchestrator Service that an ORDER_CREATED to Payment Service.
3. The Payment Service got the ORDER_CREATED command and does the necessary updates and sends the command to Order and Restaurant Service that an ORDER_PAID.
4. The Order and Restaurant Service got the ORDER_PAID command and do the necessary updates.
5. The Restaurant Service sends the command to Order and Delivery Service that an ORDER_PREPARED.
6. The Order and Delivery Service got the ORDER_PREPARED command and do the necessary updates.
7. Finally, Delivery Service sends the command to Order Service that ORDER_DELIVERED to the Order Service, and the Order state changed from PENDING to COMPLETE.

Conclusion

CHOREOGRAPHY-Event-Based (Message Broker) could be a case where you can end in a deadlock because one service is dependent on the other and what if the other is dependent on the other, so if you have a very less number of events it will be very good but if let's say you have more number of events there could be a point where you might miss the sequence of the workflow and it might be tedious to test individual microservices and integration tests when you have too many events, in terms of ORCHESTRATION Command-Based (Service Provider) there is a single service which is going to interact with different microservices and now orchestration needs to have mapping on what each service does which again defeats the purpose of individual microservices concept where your orchestration service knows what is service does and if let's say there is a change is a payment service it might end up the changing the orchestration service as well. So this is one more pattern of implementing SAGAS however it's up to you to decide which one to go for based on your architectural use case.