Saga Pattern
Explore the Saga pattern to understand how it handles distributed transactions by using a series of local transactions with compensating steps. Learn coordination methods, failure handling, and observability to design scalable, reliable multi-service workflows.
When moving away from a monolith, a single database transaction can no longer guarantee atomicity. If a process spans multiple services, like order, payment, and shipping, a failure at the final step can leave the system in an inconsistent state (e.g., a paid order that is never shipped).
The Saga pattern solves this by replacing one global transaction with a sequence of local transactions. Each forward step has a corresponding compensating transaction that semantically undoes the work (e.g., reversing a payment rather than just deleting a row) if a subsequent step fails.
The following diagram illustrates the flow of forward transactions and the backward “undo” logic through a typical three-service e-commerce saga:
The core components that make a saga work include the following:
Saga participants: Each microservice owns exactly one local transaction in the sequence and exposes both a forward operation and a compensating operation.
Saga execution coordinator or event channel: Either a centralized orchestrator directs the workflow, or an event bus connects participants in a choreography model.
Compensating transactions: Each forward step has a corresponding reverse operation that undoes the business effect of the completed step.
Saga log: A persistent record that tracks which steps have been completed, which are pending, and which compensations must be executed on failure.
Unlike 2PC, sagas do not lock resources across services. They trade strong consistency for availability and partition tolerance, achieving ...