- What is distributed transaction?
- What are different patterns for distributed transactions?
- What is SAGA Pattern?
- Why Saga when we have 2 phase commits?
- How to implement Saga Pattern?
- What is Events/Choreography approach for implementing Saga Pattern?
- How rollbacks are performed under Events/Choreography approach for implementing Saga Pattern?
- What are the benefits and drawbacks of using Saga’s Event/Choreography design?
What is distributed transaction?
Consider you have a application composed of microservices, where each Microservices have its own database:
In this example:
All these operations have to happen as part of one transaction, and if one of the operations fails, all previous operations have to rollback.
Transactions provide atomicity of multiple operations but on a single database. Here, this is not a single database, but multiple databases.
So what we need here is Distributed Transaction.
Distributed Transaction is not something which is supported by databases, but we have to write our services in such a way that we can implement distributed transactions.
What are different patterns for distributed transactions?
What is SAGA Pattern?
The saga design pattern is a way to manage data consistency across microservices in distributed transaction scenarios. A saga is a sequence of transactions that updates each service and publishes a message or event to trigger the next transaction step. If a step fails, the saga executes compensating transactions that counteract the preceding transactions.
The first transaction in a saga is initiated by an external request corresponding to the system operation, and then each subsequent step is triggered by the completion of the previous one.
Subsequent services will get an event over messaging bus to perform the operation. If any of service fails to perform the operation, it publishes a failure event which is listened by previous services which have performed their operation and based on that they rollback their operation.
In a very high-level design a saga pattern implementation would look like the following:
Why Saga when we have 2 phase commits?
Distributed transactions like the two-phase commit (2PC) protocol require all participants in a transaction to commit or rollback before the transaction can proceed. However some participant implementations, such as NoSQL databases and message brokering, don’t support this model.
How to implement Saga Pattern?
What is Events/Choreography approach for implementing Saga Pattern?
In Choreography approach participants exchange events without a centralized point of control.
The first service executes a transaction and then publishes an event. This event is listened by one or more services that execute local transactions and publish (or not) new events.
The distributed transaction ends when the last service executes its local transaction and does not publish any events or the event published is not heard by any of the saga’s participants.
How rollbacks are performed under Events/Choreography approach for implementing Saga Pattern?
Rolling back a distributed transaction does not come for free. You have to implement another compensating transaction for what has been done before.
What are the benefits and drawbacks of using Saga’s Event/Choreography design?
- Good for simple workflows that require few participants and don’t need a coordination logic.
- Doesn’t require additional service implementation and maintenance.
- Doesn’t introduce a single point of failure, since the responsibilities are distributed across the saga participants.
- Workflow can become confusing when adding new steps, as it’s difficult to track which saga participants listen to which commands.
- There’s a risk of cyclic dependency between saga participants because they have to consume each other’s commands.
- Integration testing is difficult because all services must be running to simulate a transaction.