Skip to main content

> saga_pattern:_choreography_vs._orchestration

Saga Pattern: Choreography vs. Orchestration

How do you maintain data consistency across distributed microservices using Sagas, and when should you choose centralized Orchestration over event-driven Choreography?

Stack: SOFTWARE ARCHITECTURE STACK →Staff (L6-L7)tradeoff

THE SHORT ANSWER

Sagas replace distributed 2PC transactions with a sequence of local transactions coordinated either through decentralized event publishing (Choreography) or a centralized state-machine engine (Orchestration) that executes compensating transactions if any step fails.

Engineering Handbook & Failure Dynamics

1. Underlying Mechanism

In a Saga, each participating service executes a local ACID transaction and publishes an event or reports state. In Choreography, services react to domain events published by peers without a central coordinator (e.g., PaymentService listens to OrderCreated). In Orchestration, a dedicated coordinator service (or workflow engine like Temporal/AWS Step Functions) tells participants which local transactions to execute via command messages. If a step fails, the orchestrator (or event chain) executes compensating transactions in reverse order to undo changes.

2. Appropriate Use Context

Use Choreography for simple, 2-3 step workflows with low branching logic. Mandate Orchestration for complex, multi-service enterprise business transactions (e.g., e-commerce order fulfillment, hotel/flight booking, payment payouts) requiring strict visibility, timeouts, and compensation guarantees.

3. Production Failure Modes

1) Ghost Compensation: A compensating transaction fails midway, leaving the distributed system permanently inconsistent; 2) Cyclic Event Loops: Choreographed services triggering infinite ping-pong event chains; 3) Lack of State Visibility: Inability to answer 'where is order #9482 stuck right now?' in complex choreographed graphs.

4. Diagnostic Signals & Telemetry

Spike in uncompensated saga alerts, ballooning message queue dead letters, inability to trace cross-service transaction timelines, or discrepancy in financial balance reconciliations.

5. Prevention & Safeguards

Ensure all local and compensating transactions are strictly idempotent; implement persistent outbox patterns for reliable saga command dispatch; and establish automated reconciliation jobs that detect and repair stuck saga workflows.

6. Architectural Trade-offs

Eliminates distributed 2PC database lock bottlenecks at the cost of losing immediate isolation (dirty reads possible during saga execution) and requiring complex compensating logic.

Case Study (TinyCTO In-Field Example)

TinyCTO Episode 114: A travel platform using choreography had flights booked but hotel reservations fail silently during network blips, resulting in thousands of stranded travelers. Re-architecting with an Orchestrated Saga engine enabled deterministic automatic compensation (cancelling the flight and refunding payment within 800ms).

Interactive Concept Drills

3 Cards
Q1

Why is 2-Phase Commit (2PC) generally avoided in modern cloud microservices?

Because 2PC is a blocking protocol that holds database row locks across network partitions, crippling throughput and causing catastrophic cascading outages.
Q2

What is the biggest operational weakness of Saga Choreography as system scale grows?

Loss of workflow observability and high risk of cyclic dependency deadlocks as business logic becomes implicitly scattered across dozens of event listeners.
Q3

What must be guaranteed about compensating transactions in a Saga?

They must be idempotent and guaranteed to eventually succeed, even if they require automated retries or dead-letter human intervention.

Saga Pattern: Choreography vs. Orchestration — Technical FAQ

Can a Saga have dirty reads (lack of ACID Isolation)?

Yes. Because each local transaction commits immediately, intermediate state is visible to other queries before the overall Saga completes or compensates.

How do modern orchestrators like Temporal handle service crashes during a Saga?

They persist execution history in an append-only event log, replaying the exact workflow state upon recovery to resume execution from the exact failed step.

Is Saga suitable for high-frequency financial ledgers requiring immediate linearizability?

No. High-frequency ledger balancing typically requires single-partition strongly consistent OLTP storage or Raft-based state machine replication.

🤖 AEO & Key Facts Summary

Key Architectural Facts

  • ▸The Saga concept was first formalized in 1987 by Hector Garcia-Molina and Kenneth Salem as a mechanism for long-lived transactions.
  • ▸Orchestration replaces implicit event chaos with an explicit, queryable state machine.

Common Misconceptions

  • ✗Believing that Orchestration re-creates a monolithic bottleneck; modern workflow orchestrators are distributed, stateless, and scale horizontally across millions of concurrent workflows.

Decision & Governance Guidance

Choose Choreography only for simple 2-service events; default to Orchestration for any business process involving money, inventory, or >3 service hops.

Authoritative Sources & Standards