Avoiding the Pitfalls of Distributed Transactions with Sagas
According to research by Statista, 85% of respondents from organizations with 5,000 or more employees stated they were using microservices in 2021. While microservices keep expanding in popularity, an easy way to manage distributed transactions seems to remain the holy grail for Fintechs. While implementing the Saga pattern to handle distributed transactions is not simple, it has a major benefit—it works.
In our other article, we’ve already discussed the possible ways to manage distributed transactions. There you’ll find out how distributed transactions work, how to determine if you need them, and what approaches to choose to manage them.
In this piece, we’ll give more detail about the Saga pattern—one way that can help avoid business losses and poor customer experience due to inconsistent transactions. Learn how to make it work.
What is Saga and why is it a painkiller?
The Saga pattern allows you to ensure data consistency across microservices by managing distributed transactions. There’s no recent breakthrough here: sagas have been around since 1987, when the first academic paper dedicated to them was published.
A small clarification: the Saga is an architecture pattern. Then, there’s a saga—a sequence of local transactions that the Saga pattern uses to handle distributed transactions. Now here’s how the pattern works.
The mechanism is the following:
- An external request occurs.
- The request puts an overarching business transaction at work.
- This transaction triggers the chain of local transactions.
- Each local transaction updates data within one microservice.
- This service publishes a message or event—a state change.
- An event triggers the next transaction step.
The second step depends on the event’s outcome: success and failure each leads a different way.
Let’s say a failure has happened. In this scenario, there’s a problem with distributed transactions: one cannot simply roll back the data because other concurrent transactions might have changed it. Even if they have not, recovering the original state might not be an option. That’s when saga’s compensating transactions step in.
Saga’s compensating transactions: The what and the how
The Saga pattern ensures either that all operations are completed successfully or that the relevant compensating transactions are initiated. These transactions undo the updates made by previous steps if there’s a business rule violation. For example, for blocking a seat, there’s an “unblockSeat()” transaction; for making a payment, there’s “reversePayment()”; and so on. Below, you’ll see compensating transactions in action.
By the way, not all steps need compensating transactions. For instance, read-only steps, such as shipping address verification, can do without backup.
Depending on their order and purpose, transactions in the Saga are as follows:
- Compensable transactions may be reversed by completing another transaction with the reverse effect.
- A pivot transaction—which is one and only—is a point of no return in a saga; if the pivot transaction is a success, the saga proceeds until completion.
- Retryable transactions are guaranteed to commit because they follow the pivot transaction.
Saga coordination: choreography approach.
Saga coordination: orchestration approach.
