Choreography vs Orchestration

## 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.