The SAGA Pattern: Orchestrating Distributed Workflows Across Service Boundaries
The SAGA pattern coordinates long-running distributed transactions by decomposing them into a sequence of local transactions, each with a compensating rollback. The critical choice between choreography (event-driven) and orchestration (centralized command) determines failure observability, deadlock risk, and operational complexity across the entire workflow.
Distributed Architecture & System Design
The SAGA Pattern: Orchestrating Distributed Workflows Across Service Boundaries
Every boundary is a failure isolation decision — and when a business transaction must span multiple service boundaries, you can no longer rely on a single database transaction to roll everything back on failure. Consider the order placement flow: to complete an order, you must reserve inventory, charge payment, and notify fulfillment — three local transactions across three independent services with three independent databases. If the payment charge succeeds but the fulfillment notification fails, you now have a charged customer with no fulfillment record. ACID guarantees cannot reach across service boundaries. The SAGA pattern is the response: decompose the transaction into a sequence of local transactions, each with an explicit compensating rollback, designed to run as if failure in any step is the default case.
Series positioning: This is Part 8 of the Distributed Architecture & System Design series. Building on CQRS and messaging topologies, this article explores multi-service workflow coordination via the SAGA pattern, contrasting choreography and orchestration before we examine the Transactional Outbox and CDC in Part 9: Distributed Transactions & CDC.
1. The Two-Phase Commit Problem Across Services
A SAGA replaces "atomicity across services" (which doesn't exist) with "eventual consistency via compensating transactions" (which does). The key insight is that each step in the SAGA must have a corresponding compensating transaction that reverses its effect — and each compensating transaction must itself be idempotent and guaranteed to succeed.
2. Choreography SAGAs
In a choreography SAGA, services react to events published by other services. There is no central coordinator — each service knows only its own step and which events to emit next.
2.1 Choreography Flow
2.2 Choreography Compensation
2.3 Choreography Limitations
| Problem | Description |
|---|---|
| No saga status query | "Is this order's SAGA complete?" requires querying every participant service |
| Distributed event graph | The workflow logic is spread across 4+ services — understanding it requires reading all of them |
| Livelock risk | Circular compensations (A compensates B's failure, B compensates C's failure, C compensates A) can loop indefinitely |
| Observability gap | A saga stalled mid-flight is invisible without cross-service event correlation |
3. Orchestration SAGAs
In an orchestration SAGA, a central saga orchestrator (a durable state machine) issues commands to each participant service and handles compensations centrally. Each service is a pure executor — it performs work when commanded and emits results.
3.1 Orchestration Flow

3.2 State Machine Implementation
Every compensating transaction must be idempotent and must never fail permanently. A compensation that throws causes the saga to enter a livelock — it cannot reach either SAGA_COMPLETE or SAGA_FAILED. If a compensation fails transiently, retry with exponential backoff. If it fails permanently, alert a human operator — the saga is stuck.
4. Temporal.io for Durable Saga Orchestration
Temporal.io provides a durable execution engine that persists saga workflow event history, allowing saga orchestrators to crash and recover without losing state:
5. Choreography vs Orchestration Decision Matrix

| Criterion | Choreography | Orchestration |
|---|---|---|
| Single point of failure | None — no central process | Orchestrator process (mitigated with Temporal/k8s HA) |
| Saga status visibility | Requires cross-service event correlation | Single orchestrator state — queryable directly |
| Workflow logic location | Distributed across all participants | Centralized in the orchestrator |
| Compensation handling | Each service handles its own | Orchestrator issues compensating commands |
| Debugging failed saga | Hard — requires log correlation across services | Easy — orchestrator state machine has full history |
| Service coupling | Participants know event names (loose) | Participants know command names (slightly tighter) |
| Best for | Simple 2–3 step workflows with stable participants | Complex workflows (5+ steps), frequent failures, human approval steps |
Start with choreography for simple flows. Migrate to orchestration when: (a) you cannot answer "is this saga complete?" without querying multiple services, (b) compensation logic involves more than 3 steps, or (c) workflow changes require coordinated releases across multiple teams.
6. SAGA Isolation and the ACD Property
SAGAs are not ACID — they are ACD: Atomic (via compensation), Consistent (eventually), Durable (each local transaction commits durably), but not Isolated. Concurrent SAGAs may observe each other's intermediate state:
Summary
| Architectural Concern | Production Rule |
|---|---|
| SAGA Workflows | Replaces distributed ACID with a sequence of local transactions coordinated with compensating rollbacks. |
| Choreography Tradeoffs | No central coordinator; services react to events; harder to trace and debug when a workflow stalls mid-flight. |
| Orchestration Durability | Central state machine issues commands and handles compensation; directly queryable; use Temporal.io for durable execution. |
| Compensating Idempotency | Compensations must be idempotent and must never fail permanently; permanent compensation failure creates livelocks. |
| Isolation Anomalies | Concurrent SAGAs may see each other's intermediate uncommitted state — mitigate with semantic locks at the resource level. |
What's Next
In the series capstone, Part 9: Distributed Transactions, Transactional Outbox & CDC solves the fatal dual-write hazard between database transactions and message brokers, implementing Debezium WAL tailing and Inbox deduplication for end-to-end exactly-once business outcomes.
This article was developed with AI-assisted deep search, specification cross-referencing, and technical research synthesis.