Understanding the Saga Pattern for Distributed Transactions in Microservices

One of the most powerful transaction types is the two‑phase commit, where the commit of the first transaction depends on the completion of a second; it is especially useful when multiple entities must be updated simultaneously, such as confirming an order and updating inventory.

In a microservices architecture, each service owns its own database, so the simplicity of local two‑phase commit can no longer be used to maintain system‑wide consistency.

When this capability is lost, traditional RDBMS become a poor storage choice, while NoSQL databases like Couchbase can perform the same "single‑entity atomic transaction" dozens of times faster, which is why many companies using microservices also adopt NoSQL.

To illustrate, consider a high‑level e‑commerce microservice architecture:

In this example, you cannot place an order, charge the customer, update inventory, and ship the product all within a single ACID transaction; a distributed transaction is required.

Distributed transactions are notoriously difficult; designers must consider transient states, service isolation, and final consistency between services and rollbacks.

Fortunately, the Saga pattern—first described in a 1987 paper—offers a proven solution.

Saga Pattern

Saga is a series of local transactions, each updating data within a single service. The first transaction is triggered by an external request, and each subsequent step is triggered by the completion of the previous one.

Using the e‑commerce example, a high‑level Saga implementation looks like this:

There are two popular ways to implement a Saga:

Event‑driven Choreography : Services emit and listen to events without a central coordinator.

Command‑driven Orchestration : A coordinator service centrally decides the order and logic of the Saga steps.

Let’s explore each implementation.

Event‑driven Choreography

In the choreography approach, the first service performs its local transaction and publishes an event. Other services listen to that event, perform their own local transactions, and may publish new events.

The Saga ends when the last service completes its transaction and does not publish any further events, or when no participant receives any more events.

Applied to the e‑commerce example, the flow looks like this:

Order Service saves a new order, sets its status to *pending*, and publishes ORDER_CREATED_EVENT .

Payment Service listens to ORDER_CREATED_EVENT , charges the customer, and publishes BILLED_ORDER_EVENT .

Stock Service listens to BILLED_ORDER_EVENT , updates inventory, prepares the items, and publishes ORDER_PREPARED_EVENT .

Delivery Service listens to ORDER_PREPARED_EVENT , selects and delivers the products, then publishes ORDER_DELIVERED_EVENT .

Order Service finally listens to ORDER_DELIVERED_EVENT and marks the order as *completed*.

If order status tracking is needed, the Order Service can simply listen to all events and update its state accordingly.

Rollback in Distributed Transactions

Rolling back a distributed transaction is not free; it usually requires a compensating transaction to undo previously completed steps.

For example, if the Stock Service fails, the rollback flow might be:

Stock Service publishes PRODUCT_OUT_OF_STOCK_EVENT .

Order Service and Payment Service listen to this event: Payment Service refunds the customer. Order Service sets the order status to *failed*.

Defining a shared transaction ID for every transaction is crucial so that all listeners can immediately identify which transaction an event refers to.

Benefits and Drawbacks of Event‑driven Choreography

Choreography is natural for the Saga pattern: it is simple, easy to understand, requires little effort to build, and keeps participants loosely coupled because they have no direct knowledge of each other. It works well for transactions with 2‑4 steps.

However, as more steps are added, the approach can become chaotic, making it hard to track which services listen to which events, potentially creating circular dependencies. Testing also becomes difficult because all services must be running to simulate the transaction.

The next article will explain how the Command/Orchestration approach addresses many of these issues.