You're implementing a saga for an e-commerce checkout that touches Order, Payment, and Shipping services. Compare a choreography-based saga (services react to each other's events) with an orchestration-based saga (a central coordinator issues commands) for this flow - how does each work mechanically, and what are the trade-offs as the number of participating services grows?

## Two ways to coordinate a saga Choreography and orchestration are the two ways to coordinate the sequence of local transactions and compensations that make up a saga, and the choice mostly comes down to how much you want the coordination logic **centralized** versus **distributed** across the participating services. ## Choreography: everyone reacts to events In a choreography-based saga, there's no dedicated coordinator process. Each service completes its own local transaction and then publishes a **domain event** describing what happened - for example, the Order service commits an order in 'pending' state and publishes `OrderCreated`. Other services subscribe to the events relevant to them: 1. the Inventory service listens for `OrderCreated`, reserves stock, commits its own local transaction, and publishes `InventoryReserved` (or `InventoryReservationFailed`); 2. the Payment service listens for `InventoryReserved`, attempts to charge the customer, and publishes `PaymentCompleted` or `PaymentFailed`. The saga's overall logic - the sequence of which step follows which - is nowhere written down as a single artifact; it emerges from the sum of all the individual event subscriptions across every service. Compensation works the same way in reverse: if `PaymentFailed` is published, the Inventory service (which subscribed to that event too) runs its own compensating transaction to release the reserved stock. ## Orchestration: one process issues commands In an orchestration-based saga, one process - the **orchestrator** - explicitly owns the saga's definition. It sends a command to the first participant ('reserve inventory'), waits for a response, and based on that response sends the next command ('charge payment'), continuing step by step. If a step reports failure, the orchestrator is responsible for issuing the compensating commands to every participant that already succeeded, in the right order. The orchestrator typically persists its own state (which step it's on) so it can resume after a crash, often implemented with a durable state machine or workflow engine. ## Why both styles exist The reason both styles exist is that they optimize for different things. | | Choreography | Orchestration | |---|---|---| | Saga definition | emerges from event subscriptions | one process explicitly owns it | | Coupling | maximally decoupled | knows about every participant | | Debugging | trace event subscriptions across many codebases | flag the step it is waiting on | Choreography keeps services maximally decoupled: a new service can join the saga just by subscribing to existing events, without any existing service needing to change or even know the new service exists. This is attractive early in a system's life, when the flow is short (2-3 steps) and the team wants to avoid introducing a new central component. But this benefit inverts as the saga grows: - with five or more participants and several failure branches, there is no single place to read and understand 'what does checkout actually do,' which makes onboarding, debugging, and testing significantly harder - you have to trace event subscriptions across many codebases to reconstruct the flow; - it's also easy to accidentally create cyclic or ambiguous event dependencies, where two services each wait on an event the other is supposed to produce first. Orchestration trades that decoupling for explicit visibility and control: the entire saga's happy path and every compensation branch live in one place, are testable as a unit, and are straightforward to modify (add a step, reorder steps) without touching the participant services' internals beyond their command handlers. The cost is that the orchestrator becomes a piece of infrastructure that must itself be highly available and correctly handle its own crashes and retries (usually solved by persisting saga state to a durable store and resuming from there), and it necessarily knows about every participant, which can become a coupling and scaling bottleneck if it also has to encode business rules that arguably belong to the participants. ## A failure mode that shows the difference A concrete failure mode that shows the difference: in a choreography saga, if a new team adds a service that subscribes to `InventoryReserved` but forgets to publish a completion or failure event, the whole saga silently stalls with no owner noticing, because no component is 'watching' the entire flow - discovering this in production often requires distributed tracing across services. In an orchestration saga, the same kind of bug (a participant not responding) is easier to detect, because the orchestrator has an explicit timeout and step it's waiting on; it can flag 'stuck on step 3' directly. ## What real systems settle on In practice, many real systems use a **hybrid**: - **choreography** for short, stable, low-branching subflows (e.g., publishing an `OrderPlaced` event that a few independent services react to for notifications or analytics, where failure doesn't need compensation), - **orchestration** for the core business-critical saga with several steps and compensation branches (e.g., checkout, loan approval, travel booking), where correctness and observability of the full flow matter more than minimizing coupling. Once a workflow has several steps each with its own compensation, an explicit, inspectable orchestrator tends to win over an implicit, event-driven web of subscriptions.