Sagas in Microservices: Managing Complex Transactions in Distributed Systems

In a microservices architecture, workflows can be classified as short or long-running. Short workflows typically involve a single microservice is completed quickly. Long workflows, also known as sagas[1], involve multiple microservices and can take a long time to complete.

Sagas in Microservices[2]

The steps involved in executing a saga are as follows:

1. The saga coordinator sends a request to the first service to execute the first local transaction.
2. If the first local transaction succeeds, the service sends a message to the saga coordinator indicating that the transaction was successful.
3. The saga coordinator then sends a request to the second service to execute the second local transaction.
4. If the second local transaction succeeds, the service sends a message to the saga coordinator indicating that the transaction was successful.
5. The aforementioned procedure persists until the execution of all the regional transactions.
6. In case of a local transaction failure, the saga coordinator will perform a compensating transaction to revoke the effects of that transaction.
7. Once all of the local transactions have been executed, the saga coordinator will send a final message to the client indicating whether the overall transaction was successful or not.

Let’s take an instance to comprehend the contrast between brief and prolonged workflows (sagas). Suppose a user wants to register for an online course. The registration process involves several steps, such as checking the course availability, processing payment, and updating the user’s account. These steps can be handled by separate microservices, but the entire process can be completed quickly. In this example, the registration process is a short workflow. Each step is completed quickly, and there is no need to manage the transaction across multiple services.

Suppose you’re booking a flight and a hotel at the same time involves multiple steps and interactions between different services. To handle this scenario using Sagas in a microservices architecture, we can design a saga that coordinates the interactions between the booking flight and booking hotel services.

Here’s an example of how the saga could work

Forward and backward recovery in travel bookings[3][4]

1. A saga is initiated by a client request to a coordinator service.
   The coordinator service starts the saga and sends a message to the first service in the saga.
2. The first service performs its part of the transaction and sends a response to the coordinator service indicating whether it was successful or not.
3. If the response is successful, the coordinator service sends a message to the next service in the saga to perform its part of the transaction.
   If the response is not successful, the coordinator service uses backward recovery to undo any changes made by the first service.
4. The subsequent services perform their parts of the transaction, and the coordinator service uses forward recovery to keep track of the progress made in the saga.
5. If all services successfully complete their parts of the transaction, the coordinator service confirms the saga and sends a response to the client indicating that the transaction was successful.
6. If any service fails, the coordinator service uses backward recovery to undo any changes made by the previous services in the saga, ensuring data consistency.

In summary, forward recovery is used to keep track of the progress made in the saga, allowing the coordinator service to resume the saga from the last successfully completed step. Backward recovery is used to undo any changes made by a service if an error occurs, ensuring data consistency and preventing partial failures. By using forward and backward recovery techniques in the execution of a saga, we can ensure that the entire transaction is executed as an atomic unit, either succeeding or failing as a whole. This helps to maintain data consistency and integrity and prevents partial failures that can cause data inconsistencies.

Key benefits of using Sagas

1. Sagas can help in maintaining data consistency across multiple services. By using sagas to manage transactions, businesses can ensure that customer orders are processed accurately and efficiently. Sagas are particularly useful in e-commerce applications, where transactions can involve multiple services, such as inventory management, payment processing, and shipping.
2. Sagas can provide a structured approach to managing complex business transactions across multiple services. With sagas, each service involved in the transaction knows exactly what its role is and what needs to be done to complete the transaction. This helps to reduce the complexity of handling distributed transactions and makes it easier to track the progress of a transaction.
3. Sagas can also improve the fault tolerance and resiliency of microservices architectures. If one service fails, the saga coordinator can initiate a compensating action to undo the effects of the failed action and recover from the failure.

Conclusion

Sagas are an essential tool for managing distributed transactions in a microservices architecture. They provide a structured approach to managing complex business transactions across multiple services, ensuring that data remains consistent and that transactions complete successfully. Whether you’re building an e-commerce platform or any other microservices-based application, sagas are a valuable tool for managing complex workflows and improving the fault tolerance and resiliency of your system.

You could further enhance the modularity and scalability of your microservices-based application with an open-source toolchain such as Bit which allows your teams to independently publish, version, document, test, and share individual components such as functions, UI elements, or data models, that can be reused across multiple microservices. Learn more here.

References

1. https://dominik-tornow.medium.com/paper-summary-sagas-395ef2a9a575
2. https://robertleggett.blog/2019/03/17/when-should-you-choose-choreography-vs-orchestration-for-your-microservices-architecture/
3. https://medium.com/javarevisited/top-5-design-patterns-asked-in-java-developer-interview-67df7b3c1599
4. https://www.youtube.com/watch?v=0W8BtIwh824&ab_channel=Temporal

From monolithic to composable software with Bit

Bit’s open-source tool help 250,000+ devs to build apps with components.

Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.

→ Learn more

Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:

→ Micro-Frontends

→ Design System

→ Code-Sharing and reuse

→ Monorepo

Learn more:

How We Build Micro Frontends

How we Build a Component Design System

How to reuse React components across your projects

5 Ways to Build a React Monorepo

How to Create a Composable React App with Bit