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 the second; it is especially useful when you need to update multiple entities simultaneously, such as confirming an order and immediately updating inventory.

However, when using microservices, things become more complex. Each service is an independent system with its own database, and you can no longer rely on the simplicity of local two‑phase commit to maintain consistency across the whole system.

When you lose this ability, traditional RDBMS becomes a poor storage choice, because you can achieve the same “single‑entity atomic transaction” but NoSQL databases like Couchbase can be dozens of times faster. This is why most companies using microservices also adopt NoSQL.

To illustrate, consider the following high‑level microservice architecture for an e‑commerce system:

In the example above, you cannot place an order, charge the customer, update inventory, and trigger delivery all within a single ACID transaction. To consistently execute the whole flow you need a distributed transaction.

Implementing distributed transactions is difficult, and transactions are no exception. Handling transient states, service isolation, and rollback while achieving eventual consistency must be considered during design.

Fortunately, after more than twenty years of experience with distributed transactions, we have good patterns. The pattern discussed here is the Saga pattern.

Saga Pattern

One of the most famous patterns for distributed transactions is Saga. The first paper was published in 1987, and it has become a popular solution ever since.

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

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

There are several ways to implement a Saga; the two most popular are:

Event/Choreography : When there is no central coordinator, each service emits and listens to events from other services and decides whether to act.

Command/Orchestration : A coordinator service centrally decides the order of Saga steps and contains the business logic.

Let’s dive deeper into each implementation to see how they work.

Event/Choreography

In the Event/Choreography method, the first service performs its transaction and then publishes an event. One or more other services listen to that event, perform their local transactions, and may publish new events.

When the last service completes its local transaction and does not publish any further events, the distributed transaction ends, or no Saga participants hear any more events.

Here is how it looks in our e‑commerce example:

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

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

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

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

Order Service listens to ORDER_DELIVERED_EVENT and sets the order status to completed.

If you need to track order status, the Order Service can simply listen to all events and update its status accordingly.

Distributed Transaction Rollback

Rolling back a distributed transaction is not free. Usually you must implement another operation/transaction to compensate previously completed actions.

Assume the Stock Service fails during the transaction. The rollback would look like this:

Stock Service produces PRODUCT_OUT_OF_STOCK_EVENT.

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

Defining a common shared ID for each transaction is crucial so that whenever an event is emitted, all listeners can immediately know which transaction it references.

Benefits and Drawbacks of Event/Choreography

Event/Choreography is a natural way to implement the Saga pattern; it is simple, easy to understand, requires little effort to build, and all participants are loosely coupled because they have no direct knowledge of each other. If your transaction involves 2‑4 steps, it may be very suitable.

However, as you keep adding extra steps, this approach quickly becomes messy because it is hard to track which services listen to which events. It can also introduce circular dependencies between services, as they must subscribe to each other's events.

Finally, testing implementations using this design is tricky; to simulate transaction behavior you need to run all services.

In the next article I will explain how using the Command/Orchestration Saga implementation solves many of the problems of the Event/Choreography approach.