Saga Design Pattern : What it is and Why use it?
What is Saga ?
Saga pattern is all about coordinating a complex transaction process across multiple steps/service .
When Saga is needed ?
It’s used to implement Distributed transaction. In real world microservice architecture sometime traditional ACID transactions aren’t feasible due to the distributed nature of the system.
What are Distributed transaction ? Why distributed transaction are hard to implement ?
Genrally a service has its own database. Some business transactions, however, span multiple service so you need a mechanism to implement transactions that span services.
In a distributed transaction scenario, as the transaction spans several services, ensuring ACID always remains challenge.
The second challenge is managing the transaction isolation level. It specifies the amount of data that is visible in a transaction when the other services access the same data simultaneously. In other words, if one object in one of the microservices is persisted in the database while another request reads the data, should the service return the old or new data?
Why Saga?
- Coordinating complex transactions is challenging: In a distributed transaction, multiple services need to coordinate with each other to ensure that the transaction is executed atomically. Coordinating these transactions is challenging, especially when different services or participants have different failure modes and recovery requirements.
- Traditional 2-phase commit protocols, have their own problems. 2PC, which were commonly used for distributed transactions. 2PC have performance and scalability issues, which make them less suitable for modern distributed systems.
Alternatives to Saga?
- Two-phase commit protocol (2PC): The 2PC protocol is a traditional approach. It ensures that all participants agree to commit or abort a transaction before proceeding.
- Optimistic concurrency control: Optimistic concurrency control is a technique for managing conflicts in distributed transactions by assuming that conflicts are rare and checking for conflicts only when committing the transaction. This is a more efficient approach, but it requires careful management of conflicts and error handling.
How Saga Works ?
- In a saga, the transaction is broken down into a series of smaller, loosely coupled steps or sub-transactions, each of which corresponds to a service call or a message exchange between services.
- Each step of the saga is implemented as a local transaction within the scope of the corresponding service, and it updates the local state of the service as well as publishes a message or event to trigger the next step of the saga.
- If any step of the saga fails, the saga coordinator triggers a compensating transaction, which reverses the effects of the previous steps and brings the system back to a consistent state.
- This way, saga pattern ensures that the transaction is eventually completed or compensated, even in the presence of failures,.
Saga Components:
- Saga Coordinator: It is responsible for managing the overall execution. It coordinates various sub-transaction. It is responsible for initiating each sub-transaction and monitoring its progress.
- Transactional Participants: Transactional Participants are microservices that participate in Saga. They execute he sub-transactions and update their local state as required. Each participant is responsible for executing a local transaction that corresponds to a particular step in the Saga.
Compensation Actions: A compensation action is the action taken by a Transactional Participant to undo the effects of a previously executed sub-transaction.
- In the event of a failure, the Saga Coordinator invokes the appropriate compensation action to undo the effects of the failed sub-transaction and restore the system to a consistent state.
- Saga Log: Saga Log is a persistent log that records the state of the Saga as it progresses. It is used to recover the state of the Saga in the event of a failure.
- Timeout Manager: Timeout Manager is responsible for detecting and handling timeouts that occur during the execution of Saga. It ensures that Saga progresses within a reasonable time frame and prevents itfrom getting stuck in an inconsistent state.
Drawbacks of Saga ?
- Complex: The Saga pattern can be complex to implement and manage, especially in large-scale systems with many services and participants. Each participant must be designed to handle both the forward and backward recovery processes, which can introduce additional complexity.
- Tough to Ensure Consistency always: Ensuring consistency across a distributed system is always a challenge. The Saga pattern relies on compensating actions to undo the effects of previously executed steps, but this can be difficult to achieve in practice, especially when compensating actions depend on external systems.
- Operational Overhead: The Saga pattern requires additional infrastructure to manage and coordinate the distributed transaction, which can introduce additional operational overhead, including monitoring, logging, and maintenance.
Real work use cases ?
It is used in many real-world payments systems to ensure transactional consistency
- E-commerce transactions: In an e-commerce system, Saga can be used to manage a transaction that involves several services, such as order management, inventory management, and payment processing. Saga ensures that the customer is charged only if the order can be fulfilled, and that the inventory is updated only if the order is successful.
- Travel Booking: Saga can be used to manage a transaction that involves several services, such as flight booking, hotel booking, and car rental.
- Banking and Finance transactions: Saga can be used to manage a transaction that involves several services, such as account management, fund transfer, and fraud detection.
tldr: Saga architecture pattern is used to implement distributed transactions in a microservice-based application.
