Transactions in Distributed System - SAGA Pattern

In many monolithic applications, transactions ensure consistency and isolation when making changes to the application state.

Achieving these properties is usually simple:

The application interacts with a single database that guarantees consistency, using frameworks that support initiating, committing, or rolling back transactional operations.

For example in Stock Buying App, A single logical transaction may involve multiple distinct entities; for instance, when placing an order, it may be necessary to update transactions, reserve stock positions, and charge fees.

In Microservices Application its not easy to achieve as Data ownership is decentralized, ensuring a single owner for each “source of truth.” This level of decoupling helps you gain autonomy, but you sacrifice some of the safety you were previously afforded, making consistency an application-level problem. Decentralized data ownership also makes retrieving data more complex. Queries that previously used database-level joins now require calls to multiple services. This is acceptable for some use cases but painful for large data sets.

Availability also impacts your application design. Interactions between services might fail, causing business processes to halt, leaving your system in an inconsistent state.

By contrast, in your microservice application, each of the actions in figure is per- formed by a distinct service responsible for a subset of the application state. Decentralized data ownership helps ensure services are independent and loosely coupled, but it forces you to build application-level mechanisms to maintain overall data consistency.

Let’s say the service of an order is responsible for coordinating the stock-selling process. It calls account transactions to reserve stock and then the fees service to charge the customer. But that transaction fails.

At this stage, your system is in an inconsistent state: the stock is reserved, an order is created, but you haven’t charged the customer. You can’t leave it like this — so the implementation of orders needs to initiate corrective action, instructing the account transactions service to compensate and remove the stock reservation.

This might look simple, but it becomes increasingly complex when many services are involved, transactions are long-running, or an action triggers further interleaved downstream transactions.

In Distributed Environment every services connected to distributed decentralized databases in this case achieving Automicity is difficult .

Why can’t you use distributed transactions?

When you Faced this problem, your first impulse might be to design a system that achieves transactional guarantees across multiple services. A common approach is to use the two- phase commit (2PC) protocol. In this approach, you use a transaction manager to split operations across multiple resources into two phases: prepare and commit , like below figure :

2PC Commit

This sounds great—like what you’re used to. Unfortunately, this approach is flawed. First, 2PC implies synchronicity of communication between the transaction manager and resources. If a resource is unavailable, the transaction can’t be committed and must roll back. This in turn increases the volume of retries and decreases the avail- ability of the overall system. To support asynchronous service interactions, you would need to support 2PC with services and the messaging layer between them, limiting your technical choices.

How to solve Transaction issue in Distributed Environment using SAGA Pattern .

What is Saga ?

A sequence of local transactions. Each transaction updates data within a single service, and each service has its own database.

Sagas are mechanisms to maintain data consistency in a microservice architecture without having to use distributed transactions. You define a saga for each system command that needs to update data in multiple services. A saga is a sequence of local transactions. Each local transaction updates data within a single service using the familiar ACID transaction frameworks and libraries mentioned earlier.