The Saga Pattern
Run a business transaction across services as a series of local steps with compensations.
In microservices, an order may touch the Order, Payment and Inventory services, each with its own database. A single ACID transaction across them is not practical.
A saga splits the work into local transactions. If a later step fails, the saga runs compensating actions to undo the earlier steps — refund the payment, release the stock.
Diagram
Key concepts
- Choreography
- Each service listens for events and publishes the next one. No central coordinator; harder to follow as it grows.
- Orchestration
- A saga orchestrator tells each service what to do and tracks state. Easier to reason about and monitor.
- Compensating transaction
- A business-level undo, such as a refund. It is a new action, not a database rollback.
- Pivot step
- The point after which the saga can only go forward, e.g. once goods are shipped.
- Semantic lock
- Marking records as PENDING so other operations know they are in flux.
Trade-offs
Benefits
- Data consistency across services without distributed locks
- Each service keeps its own database and autonomy
- Explicit modelling of failure paths
Costs
- Only eventual consistency — intermediate states are visible
- Compensations must be designed for every step
- Debugging long-running flows needs good tracing
Use it when
- Business processes spanning several services: orders, bookings, onboarding
Common mistakes
- Non-idempotent steps that misbehave on retried messages
- Compensations that can themselves fail without retry
- Choreography that nobody can draw any more — switch to orchestration
Interview questions
Q1Why not use a two-phase commit across services?
Two-phase commit holds locks across services while waiting for the coordinator, hurting availability and coupling services to one transaction manager. Many cloud databases and brokers don’t support it.
Q2Choreography or orchestration?
Choreography suits short flows with few services. Orchestration (Durable Functions, Temporal, MassTransit sagas) suits longer flows because the state and steps are in one place.
Q3What makes a good compensating action?
It is idempotent, retryable and business-meaningful — a refund or cancellation that leaves an audit trail rather than silently deleting data.
Related lessons
Messaging & Microservices
Microservices Design Patterns
Decomposition, integration, data, resilience and deployment patterns for service-based systems.
Messaging & MicroservicesMessage Brokers: RabbitMQ vs Kafka vs ActiveMQ
Queues and logs for decoupling services — and how the three popular brokers differ.
APIs & SecurityIdempotency & Preventing Double Payments
Make retries safe, so a timeout never charges a customer twice.