Saga Design Pattern

The Saga Design Pattern is a microservices architectural pattern to implement a transaction that spans multiple services.

A saga is a sequence of local transactions. Each service in a saga performs its own transaction and publishes an event. The other services listen to that event and perform the next local transaction.

If one transaction fails for some reason, the saga also executes compensating transactions to undo the impact of the preceding transactions.

Saga Design pattern provides a consistent view of the system by guaranteeing that when all steps are complete, either all operations succeed or compensating actions undo all the work.

You expect interservice calls and communication with third-party systems in a microservices-based application. Therefore, it’s best to design for eventual consistency: retry for recoverable errors and expose compensating events that eventually amend non-recoverable errors.

Types of Sagas

Orchestration-Based Saga
In this approach, there is a Saga orchestrator that manages all the transactions and directs the participant services to execute local transactions based on events. This orchestrator can also be thought of as a Saga Manager.

Choreography-Based Saga
In this approach, there is no central orchestrator. Each service participating in the Saga performs its transaction and publishes events. The other services act upon those events and perform their transactions. Also, they may or not publish other events based on the situation.

Implementing Saga

Since a saga is finally a description of a business process, a model-based approach is obvious here. The Business Process Modeling Notation (BPMN) has established as the de facto standard to describe a business process.

To implement saga, we can use task and workflow engines such as Apache Airflow, Apache Camel, or Conductor. You can also write your own event handlers using systems based on Kafka, RabbitMQ, or ActiveMQ.

Advantages and Disadvantages of the Saga Pattern:

It helps to maintain data consistency across multiple services without tight coupling.

However, the main disadvantage of the Saga Pattern is the apparent complexity from a programming point of view.

Please refer https://skolaparthi.com/gateway-routing-pattern/

Conclusion

In this article, we discussed the Saga architecture pattern to implement distributed transactions in a microservice-based application.