Orchestration vs choreography: a conductor, or a dance?

Orchestration puts one component — an orchestrator (often a workflow engine) — explicitly in charge: it calls service A, waits, calls service B, handles the error if B fails, and drives the whole process from a single place that knows the flow. Choreography has no central controller: each service emits events ("OrderPlaced," "PaymentTaken") and other services subscribe and react on their own. The logic of "what happens next" isn’t written down in one place — it emerges from who reacts to which event.

You don’t have to choose one for the whole system. A common, healthy split: orchestrate the parts that need a guaranteed outcome — a checkout that must take payment, reserve inventory and create a shipment, with compensation if any step fails (this is the classic saga pattern, and an orchestrated saga keeps the rollback logic in one legible place). Then choreograph the loosely-coupled reactions around it — "OrderShipped" fires an event, and the emails service, analytics service and loyalty service each react independently, no coordinator needed and no reason to couple them to the checkout flow.

Orchestration’s great gift is visibility: the entire process is written in one workflow, so you can see it, trace it, and change it in a single place — and the orchestrator can own retries and compensation coherently. Its cost is coupling: every service now depends on the orchestrator, which becomes a place changes funnel through and a potential bottleneck or single point of failure.

Choreography inverts both. Services stay beautifully decoupled — you can add a new reaction by subscribing to an existing event, touching nothing that already runs. But the end-to-end process becomes emergent: it exists only as the sum of everyone’s subscriptions, so answering "what happens when an order is placed?" means chasing events across a dozen services, and a subtle bug (two services reacting to the same event, or a missing subscriber) can be genuinely hard to see. Decoupling and legibility pull in opposite directions; you’re choosing which one to spend.

An order must take payment, reserve inventory, and create a shipment — and if inventory reservation fails after payment, the payment has to be refunded. That’s a transaction with real ordering and compensation, so an orchestrated saga fits: a workflow engine calls each step, and if a later step fails it runs the compensating actions (refund, release) from one place you can actually read and audit. Scattering that rollback logic across event handlers is how money quietly goes missing.

Once the order is confirmed and shipped, though, a swarm of things should happen that don’t need coordination: send a confirmation email, update analytics, award loyalty points, notify the warehouse dashboard. Here choreography shines — "OrderShipped" is published, and each of those services reacts independently. Adding a "text the customer" feature later means one new subscriber, with zero changes to the fulfillment workflow. Orchestrate the money-critical core; choreograph the reactions around it.