The Saga Pattern: Transactions Across Microservices

Why it exists

In a microservices architecture, each service typically owns its database. This makes it impossible to use a traditional, all-or-nothing ACID transaction across multiple services. The Saga pattern was created to manage data consistency for operations that span these distributed systems, ensuring a process either fully completes or is fully undone.

The mental model

Think of a saga as a business process with a built-in contingency plan. Each step in the process is a local transaction within a single service, and each step has a corresponding "undo" action, called a compensating transaction. If you book a flight and the subsequent hotel booking fails, the saga automatically runs the "cancel flight" action to roll back the entire operation.

How it works

A saga breaks a large distributed transaction into a sequence of smaller, local transactions. Each local transaction completes its work atomically within its own service, updates its database, and then triggers the next transaction, usually via an event or message. If any transaction in the sequence fails, the saga executes compensating transactions in reverse order to undo the changes made by the preceding successful transactions. This ensures the system eventually returns to a consistent state.

When to use it

Use the Saga pattern for long-running business processes that need to coordinate multiple services, like an e-commerce checkout that involves payment, inventory, and shipping services. It's ideal when you need eventual consistency and can't lock resources for a long time, making a traditional two-phase commit impractical.

When not to use it

Avoid sagas if you require strict ACID guarantees, especially isolation. Because a saga commits local transactions along the way, other services can see an intermediate, inconsistent state before the entire process succeeds or is rolled back. If this is unacceptable, a saga is the wrong choice. For simple workflows contained within a single service, a standard database transaction is better.

One canonical example

Booking a vacation package involves a flight service, a hotel service, and a car rental service. The saga starts by booking the flight. On success, it triggers the hotel booking. If the hotel booking succeeds, it triggers the car rental. If the car rental fails, the saga executes compensating transactions: it first cancels the hotel booking, and then it cancels the flight booking, leaving the system in its original state with no partial bookings.