Saga Choreography¶
Event-driven coordination pattern — instantiates Nested and Distributed Transaction Coordination
Coordinates a multi-service transaction with no central controller — each participant reacts to the previous step's event and emits its own, unwinding through compensating events when a step fails.
Saga Choreography runs a long, multi-service transaction with no coordinator at all. There is no central brain issuing commands; instead each participant listens for the event that means "your turn," does its local step, and publishes an event announcing the result — which is precisely the cue the next participant is waiting for. The transaction advances as a chain reaction of events rippling from service to service. When a step fails, the failing service emits a failure event, and each upstream participant that had already committed reacts by running its own compensating action in reverse order, unwinding the chain. Its defining idea is decentralized coordination through published facts: control is emergent, distributed across every participant's event handlers, and no single component ever holds the whole workflow. That absence of a center is exactly what makes it the opposite of its orchestrated twin.
Example¶
A food-delivery order flows through four independent services. The Order service publishes OrderPlaced. The Restaurant service, subscribed to that event, accepts the order and publishes OrderAccepted. The Courier service reacts by assigning a rider and publishes CourierAssigned. The Payment service, listening for that, captures the card and publishes PaymentCaptured — and the saga is complete, with no component having directed the others. Now suppose payment fails: the Payment service publishes PaymentFailed instead. The Courier service, subscribed to that event, releases the assigned rider and emits CourierReleased; the Restaurant service reacts by cancelling the ticket and emitting OrderCancelled. Each service compensated its own step by reacting to a failure event, and the order unwound cleanly — without any of them ever asking a coordinator what to do, because there was none to ask.
How it works¶
- React and publish. Each participant subscribes to the events that gate its step and, on completing, publishes an event of its own. The workflow's order lives implicitly in who subscribes to what, not in any stored plan.
- Choose the eventual-consistency contract. Because steps commit locally as the chain advances, the system is briefly inconsistent (order accepted, not yet paid); the design accepts this and defines the invariant as "converges to all-done or all-compensated."
- Compensate by reacting to failure. A failure event is just another published fact; upstream services subscribe to it and run their reverse actions, so rollback is itself choreographed rather than commanded.
- See the whole only through correlation. Since no component holds the transaction, a shared correlation ID threaded through every event is the only way to reconstruct one saga's path across services.
Tuning parameters¶
- Event granularity — how coarse or fine the published events are. Fine events make handoffs explicit and flexible but multiply subscriptions; coarse events are simpler but couple more logic into each step.
- Subscription topology — which services listen for which events. This is the real "wiring" of a choreographed saga; adding a participant means editing subscriptions, and dense topologies get hard to reason about fast.
- Compensation trigger scope — which failure events each upstream service reacts to. Broad reactions ensure nothing is left committed; narrow ones reduce spurious rollbacks but risk stranding a step.
- Correlation propagation — how rigorously the correlation ID is carried and logged on every event. Stricter propagation makes the saga observable at the cost of discipline on every publisher.
When it helps, and when it misleads¶
Its strength is loose coupling and autonomy: services depend only on events, not on a coordinator, so each can evolve and deploy independently and there is no central bottleneck or single point of failure.[1] It shines for short chains of a few autonomous services.
Its failure mode is that understanding the workflow becomes archaeology. Because the flow is scattered across subscriptions, no one place tells you what a transaction does; adding a step can create cyclic or duplicate reactions that only show up at runtime, and debugging a stuck saga means stitching events back together by correlation ID. It also has no natural home for a workflow that must expose or enforce its overall progress. The classic misuse is choreographing a long, branch-heavy business process that genuinely needs a visible state machine. The guarding discipline is to keep choreographed chains short and acyclic, invest hard in correlation-ID tracing so a saga can be reassembled, and switch to a coordinator when the flow grows complex enough that "no one holds it" stops being a feature.
How it implements the components¶
atomicity_and_consistency_objective— it embodies the eventual-consistency-with-compensation invariant explicitly: steps commit locally and the saga converges to all-done or fully-unwound rather than locking for global atomicity.compensation_and_reconciliation_plan— compensation is realized as reactive compensating events distributed across each participant's handlers, unwinding committed steps in reverse.observability_and_audit_trace— a correlation ID threaded through every event is the mechanism's only way to reconstruct and audit a single saga across services, so tracing is intrinsic, not optional.
It builds no central distributed_transaction_boundary_map, keeps no participant_commitment_registry, and owns no nested_scope_hierarchy — those centralizing artifacts belong to its twin, Saga Orchestration; choreography deliberately has no center to hold them.
Related¶
- Instantiates: Nested and Distributed Transaction Coordination — this is the coordinator-free, event-driven way to run a distributed saga.
- Sibling mechanisms: Saga Orchestration · Transactional Outbox/Inbox Pattern · Commit-Log Recovery Replay · Idempotency Key & Deduplication Store · Escrow or Reservation Hold · Manual Reconciliation Workbench · Quorum or Consensus Commit
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Saga Choreography operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it coordinates a multi-service transaction with no central controller — each participant reacts to the previous step's event and emits its own, unwinding through compensating events when a step fails.
Independent corroboration: The frozen evidence defines Saga Choreography as 'Coordinates a multi-service transaction with no central controller — each participant reacts to the previous step's event and emits its own, unwinding through compensating events when a step fails', so its operative form is Control, Automation & Runtime.
Nearest alternative: Protocol, Workflow & Routine — Saga Choreography includes features of a repeatable ordered procedure or handoff sequence that coordinates action, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Event-driven decentralized sagas with compensating actions are canonical distributed-systems architecture.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: coordinates a multi-service transaction with no central controller — each participant reacts to the previous step's event and emits its own, unwinding through compensating events….
Review resolution: Both blind reviewers agree that computer_science is the primary historical origin. Explicit reconciliation of alternate_origin_disagreement starts from reviewer_a's mechanism-specific evidence: Event-driven decentralized sagas with compensating actions are canonical distributed-systems architecture. Reviewer A proposed alternates=none, origin_mode=single_lineage, domain_reach=specialized, and encyclopedia_synthesis=false; reviewer B proposed alternates=engineering_design, origin_mode=single_lineage, domain_reach=specialized, and encyclopedia_synthesis=false. The final record retains every independently supported alternate from either review (engineering_design) without an arbitrary cap, selects origin_mode=single_lineage to represent the combined lineage evidence, and records domain_reach=specialized and encyclopedia_synthesis=false. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Choreography and Saga Orchestration solve the same problem — a multi-step transaction whose steps commit locally and are undone by compensation — and differ only in where control lives. Here it is emergent and distributed (services react to events); in orchestration it is explicit and central (a coordinator issues commands). A durable, atomically-published event stream is what a choreographed saga runs on, which is why it pairs naturally with the Transactional Outbox/Inbox Pattern.
References¶
[1] The Saga pattern (Garcia-Molina & Salem, 1987) breaks a long-lived transaction into a sequence of local transactions, each with a compensating transaction that semantically undoes it, trading strict atomicity for availability. Choreography is the decentralized realization of that pattern, where the sequence is driven by events rather than a central process. withdrawn registry ↩