In a system where several services each own one step of fulfilling an order (reserve inventory, charge payment, arrange shipping), what is the fundamental difference between coordinating those steps with choreography versus orchestration?
answer
- dance troupe vs conductor
- implicit vs explicit process state
- events (facts) vs commands (orders)
- no coordinator vs single coordinator
basics
~20 sChoreography: each service reacts to events from other services on its own, like dancers who each know their part with no director. Orchestration: one central 'conductor' service tells every other service exactly what to do and when.
solid answer
~40 sChoreography has no central coordinator - each service publishes domain events (e.g. OrderPlaced, PaymentCharged) and other services subscribe to the events they care about, deciding independently what to do next. The workflow is implicit, emerging from the sum of these reactions. Orchestration puts a single component - the orchestrator - in charge: it holds the process definition explicitly and calls each participant directly, usually via command messages (ChargePayment, ReserveInventory), waiting for replies and deciding the next step itself. Choreography trades central control for service autonomy and loose coupling; orchestration trades some autonomy for a single place to see and change the whole flow.
go deeper
Can state the one-line distinction (no coordinator vs. central coordinator) and give a simple example of each.
Can also say why each style exists (avoiding distributed transactions) and name events vs. commands as the message shapes used by each.
Connects the mechanism to concrete coupling and observability consequences, not just the definition.
Uses the distinction to reason about where to draw process boundaries across teams, not just within one flow.
## The same problem, solved in opposite directions Both patterns solve the same problem: getting several independently-deployed services to complete a multi-step business process without a shared database transaction spanning all of them. They solve it in structurally opposite ways. ## Choreography — peer-to-peer and implicit In choreography, coordination is peer-to-peer and implicit. - **Service A** finishes its work and publishes a fact about the past — an event like `OrderPlaced` — onto a broker (Kafka, RabbitMQ, SNS/SQS, etc). Service A does not know or care who, if anyone, is listening. - **Service B** subscribes to that event because it needs to react (e.g. the payment service reacts to `OrderPlaced` by charging the customer, then itself publishes `PaymentCharged`). - **Service C** subscribes to `PaymentCharged` and reserves inventory. No component holds a map of the whole process; the process only exists as the sum of these independent reactions, discoverable by grepping who-subscribes-to-what across the codebase. ## Orchestration — centralized and explicit In orchestration, coordination is centralized and explicit. One component — **the orchestrator** — encodes the process as an actual artifact: a state machine, a sequence of steps, sometimes literally a BPMN diagram or a workflow-engine definition (Temporal, AWS Step Functions, Camunda are common implementations). The orchestrator issues **commands** — imperative, addressed messages like `ChargePayment` or `ReserveInventory` — to each participant, and for every one of them it: 1. waits for a response or a completion signal, 2. updates its own persisted state, 3. decides the next step. The participants generally don't know about each other at all; they only know the orchestrator. ## Why both patterns exist at all The reason both patterns exist is that a synchronous, distributed ACID transaction across order, payment, inventory, and shipping services is impractical — it would require locking rows across service and network boundaries, killing availability and scalability. Both choreography and orchestration replace that with asynchronous, eventually-consistent coordination; they differ only in where the "who does what next" knowledge lives. ## The trade-off: coupling versus visibility The trade-off is coupling versus visibility. | Style | What it buys | What it costs | |---|---|---| | **Choreography** | keeps services decoupled from each other's existence — the payment service never calls the inventory service directly, so either can be deployed, scaled, or replaced without touching the other's code, and adding a new consumer (e.g. a fraud-check service that also listens to `OrderPlaced`) requires zero changes to the producer | nobody has a single view of process state: "is order 123 done yet?" requires reconstructing history from scattered events | | **Orchestration** | gives you that single view for free — the orchestrator's state is the answer — and makes branching, timeouts, and retries easy to express as ordinary code | it does so by making every participant reachable by, and therefore coupled to, the orchestrator's command contract, and by turning the orchestrator into a component the whole process depends on | ## How each one fails - In production, choreographed flows tend to fail silently: an event is published but nobody realizes a listener died or was never wired up, and the process just stalls with no error anywhere. - Orchestrated flows tend to fail loudly but centrally: if the orchestrator is down or buggy, no workflow of that type makes progress, and the orchestrator's owning team becomes a bottleneck for every change to step ordering. ## Where each one earns its place A concrete illustration: many e-commerce platforms let "peripheral" concerns — sending a receipt email, updating a recommendation model, awarding loyalty points — happen via pure choreography off an `OrderPlaced` event, because those consumers are independent and it's fine if one is slow or briefly down. The same platforms often use an explicit orchestrator or workflow engine for the "critical path" — payment, inventory reservation, shipment creation — where ordering, timeouts, and retries actually matter and where a stalled step needs to be visible to an on-call engineer within minutes, not discovered days later by a customer complaint.
- In choreography, are the messages passed between services usually events or commands, and why does that matter?They're events - past-tense facts like OrderPlaced that describe something that already happened, published without a specific addressee. This matters because the publisher makes no assumption about who will act on it, which is what gives choreography its loose coupling; a command like ChargePayment, by contrast, is addressed to a specific service and implies the sender knows that service exists.
- Does orchestration mean the orchestrator does all the actual work itself?No - the orchestrator only sequences and tracks the process; the actual work (charging a card, reserving stock) still happens inside the domain services it calls. The orchestrator's job is purely coordination: deciding what happens next and recording where the process currently stands.
Choreography is a flash mob: everyone learned their own part in advance and reacts to cues from those around them, with no director on site. Orchestration is a conductor leading an orchestra: one person holds the score and points at each section exactly when it should play.
saying these in an interview costs you the question
- Says orchestration means one giant service does everything itself
- Can't name what kind of message choreography uses (events) versus orchestration (commands)
- Thinks choreography has some hidden central registry tracking the workflow
- Confuses choreography with simple pub/sub having nothing to do with a business process