Saga Pattern

What it is

The Saga pattern manages transactions spanning multiple microservices. Instead of a distributed ACID transaction (costly and fragile), a saga is a sequence of local transactions where each step has a compensating action in case of failure.

Types

Choreography

Each service listens to events and decides what to do:

Order created → Inventory reserved → Payment processed → Order confirmed
                                   ↓ (failure)
                            Inventory released ← Payment rejected

Orchestration

A central orchestrator coordinates the steps:

Orchestrator → Reserve inventory → Process payment → Confirm order
            ← Compensate if any step fails

Choreography vs Orchestration

When to use it

• Transactions spanning multiple services (orders, payments, inventory)
• When eventual consistency is acceptable
• Long-running business processes (days or weeks)

When not to use it

• If you can solve it with a single database — don't add unnecessary complexity
• When you need immediate strong consistency (real-time bank transfers)
• If fewer than 3 services are involved — probably not worth it

Design principles

• Idempotency — each step must be executable multiple times without side effects
• Explicit compensations — each local transaction needs its reverse defined upfront
• Observability — without distributed tracing, debugging sagas is a nightmare
• Timeouts — define how long to wait before considering a step failed

Why it matters

In distributed systems, ACID transactions don't cross service boundaries. The saga pattern coordinates distributed transactions through a sequence of local transactions with compensations, maintaining eventual consistency without distributed locks.

References

• Saga Pattern — Chris Richardson. Canonical pattern reference.
• Sagas — Hector Garcia-Molina, Kenneth Salem, 1987. The original Princeton paper.
• Saga Pattern — Azure — Microsoft, 2024. Saga pattern implementation guide.