Saga Pattern
The Saga Pattern is a way of managing data consistency across multiple services in a distributed transaction by breaking it into a sequence of local transactions, each with a corresponding compensating action to undo it if a later step…
Definition
The Saga Pattern is a way of managing data consistency across multiple services in a distributed transaction by breaking it into a sequence of local transactions, each with a corresponding compensating action to undo it if a later step fails.
Overview
In a Microservices architecture, a single business operation — like placing an order — often needs to touch several independently owned services and databases: inventory, payment, and shipping, for example. Traditional distributed transactions (two-phase commit) don't scale well across services and can lock resources for too long, so the saga pattern instead runs a sequence of local transactions, each committed independently, with a defined compensating transaction to reverse it if something downstream fails. There are two common implementation styles. Choreography-based sagas have each service publish and listen for events, reacting to what happened previously without a central coordinator — this fits naturally with Event-Driven Architecture. Orchestration-based sagas use a central coordinator that explicitly calls each service in sequence and issues compensations if a step fails, which is easier to reason about and monitor but introduces a central point of coordination. Because sagas only guarantee eventual consistency rather than atomicity, application logic must be designed to tolerate an intermediate state where some steps have completed and others haven't yet — for example, an order might briefly show as 'payment pending' rather than instantly succeeding or failing as a whole. Resilience patterns like the Circuit Breaker Pattern are commonly used alongside sagas to handle service failures gracefully during the sequence.
Key Concepts
- Breaks a distributed transaction into a series of local transactions
- Each step has a defined compensating action to undo it on failure
- Choreography style: services react to each other's events with no central coordinator
- Orchestration style: a central coordinator drives the sequence explicitly
- Provides eventual consistency rather than strict ACID atomicity
- Avoids long-held distributed locks common in two-phase commit
- Requires idempotent operations since steps or compensations may be retried