Think about how a dinner party actually runs. Nobody stands in the kitchen barking "now chop the onions, now you pour the wine, now you set the table." Instead each person watches what's happening and reacts: the smell of garlic tells the wine-pourer it's nearly time, an empty plate tells someone to clear it. There's no conductor — just people responding to signals. That's choreography.
The problem
When a business process spans several services — say, processing an order across inventory, payment, and shipping — something has to drive the steps. The obvious move is a central orchestrator: one service that calls inventory, waits, calls payment, waits, calls shipping. It works, but now every step depends on that one coordinator. It becomes a bottleneck, a single point of failure, and a place where the logic for every workflow piles up. Each service also ends up tightly coupled to the orchestrator's view of the world, so changing one step often means redeploying the brain in the middle.
OrchestratorOne service drives every step: it calls each backend, waits, and decides what happens next. Every workflow's logic piles up here.- Step serviceDoes only what the orchestrator tells it to. It can't act until the coordinator calls — and it goes down with the coordinator.
How it works
In choreography there is no central brain. Each service does its piece of work, then publishes an event announcing what it did — OrderPlaced, PaymentCaptured, OrderShipped. Other services subscribe to the events they care about and react. The order service emits OrderPlaced; inventory hears it, reserves stock, and emits StockReserved; payment hears that and charges the card; shipping reacts to PaymentCaptured. The workflow emerges from this chain of reactions, usually over a pub/sub bus or message broker. The diagram below traces an event rippling from one service to the next, with nobody in the middle telling anyone what to do.
- ServiceAn autonomous service that does its piece of work, then publishes an event saying what it did.
- Event BusThe pub/sub channel that carries events. It routes, but never tells anyone what to do.
Emit facts, not commands. A good choreography event says what happened (PaymentCaptured) rather than what to do next (StartShipping). Facts let new consumers join later without the publisher knowing about them, while commands quietly recreate the central-coordinator coupling you were trying to escape.
When to use it
Choreography is a great fit when the workflow is simple and fairly stable, when you want services to stay loosely coupled and scale independently, and when you're already building on event-driven architecture. It's the natural coordination style for a saga that values autonomy over central control, and it pairs well with competing consumers for scaling each reaction.
Where it hurts is visibility. Because no single component owns the flow, understanding or debugging the end-to-end process means tracing events across many services. For complex workflows with lots of branching, or when you need one place to monitor and reason about the whole thing, orchestration is usually the kinder choice.