Orchestration vs choreography

When a business process spans several services (for example place order, take payment, reserve stock, ship), something has to coordinate the steps.

Orchestration: a central coordinator (the orchestrator) tells each service what to do and in what order.
Choreography: there’s no coordinator. Each service listens for events and reacts, publishing its own events in turn.

Diagram

flowchart LR
    subgraph orch [Orchestration]
        o[Order orchestrator] --> pay1[Payments]
        o --> inv1[Inventory]
        o --> ship1[Shipping]
    end
    subgraph chor [Choreography]
        ord[Orders] -- OrderPlaced --> pay2[Payments]
        pay2 -- PaymentTaken --> inv2[Inventory]
        inv2 -- StockReserved --> ship2[Shipping]
    end

At a glance

	Orchestration	Choreography
Control	Central coordinator	Distributed across services
Visibility of the process	One place shows every step	Spread across many services
Coupling	Coordinator knows all participants	Services know only events
Adding a step	Change the orchestrator	Add a new subscriber
Error handling and compensation	Centralized, explicit	Each service must handle its part
Risk	Orchestrator becomes a bottleneck or “god service”	Process becomes hard to understand and debug

Choose orchestration when

The process has many steps, strict ordering or complex compensation logic.
You need to know the status of each process instance at any moment.
The process is business-critical and must be easy to audit.

Choose choreography when

Steps are few and loosely related.
Many independent teams react to the same events.
New consumers are added often, and the publisher shouldn’t change each time.

The verdict

Use choreography for broadcasting facts between bounded contexts, and orchestration for any process you’d need to explain step by step to an auditor. Most mature systems use both: choreography between domains, orchestration within a complex workflow.

Glossary: saga

Written and edited by Abhinav Taduka, enterprise software architect.