Pattern · seen in 1 breakdown across 1 company

Choreography vs Orchestration

Two ways to run a process that spans several services: let each service react to the previous one's event with no one in charge, or let one engine own the steps and direct each service.

resilience

The mechanism

At its core: when several services handle one job, either nobody is in charge and each reacts to the last one's event, or one engine holds the steps and directs everyone. The first has nothing central to fail but cannot tell you the current status of the job. The second can, but everything depends on the engine. The engine becomes a single, shared dependency.

LIVE ARTIFACTWHO OWNS THE PROCESS?OPEN FULL SCREEN →
THE IDEATake an order that needs three services: take the order, charge payment, ship it. In choreography, each service listens for the event before it, does its step, and sends out the next event. Nobody owns the whole thing, so there is nothing central to break - but the process is written down nowhere. When payment stalls, orders pile up and no part of the system can tell you which ones or where. In orchestration, an engine holds the list of steps and tells each service when to act, so it always knows exactly where every order is. When a broken service comes back, the engine picks each order up again from the step it was on. The cost is that the engine itself becomes the one piece every order depends on.
WHAT TO TRYStart in choreography and click Payment to break it - orders pile up, and asking where one is gets no answer. Switch to orchestration and break Payment again: the engine lists every stuck order and its step. Then fail the engine, and every order stops.

Break a service and see who can still say where order #42 is - and what happens when the thing that knows goes down.

Definition

When one job needs several services to finish it - take the order, charge the card, ship the box - something has to decide what happens next. There are two ways to arrange that:

  • choreography - no one is in charge. Each service listens for an event, does its own step, and announces a new event for the next service to pick up
  • orchestration - one engine is in charge. It holds the list of steps and tells each service when to do its part
WHO OWNS THE PROCESS?
Left, services pass events along with no owner. Right, an engine holds the process and directs each service.
In choreography each service reacts to the event before it and nothing owns the process, so no one can say where an order is. In orchestration an engine holds the steps and always can, but every flow depends on it.

Choreography keeps services loosely tied, and there is nothing central to run or to fail. The catch is that the process itself is written down nowhere: it only exists in the chain of events passing between services. That makes it hard to change, and when something stalls you cannot simply ask which orders are stuck and where. Orchestration turns the process into a real thing you can look up, change, and restart from where it stopped. The price is a central engine that every flow now depends on.

This is the first choice to make. Once you decide the process needs an owner, the next question is where that engine should live - inside your service, or as a shared platform - which is what embedded vs centralized orchestration covers. Most systems start with choreography and move to some kind of engine before that second question comes up.

When it applies

01The process has many steps across many services. Especially long-running ones, where stalls are normal and you need to answer 'what is left to do for this order?' at any moment.
02The flow's logic is scattered across event handlers. When each step lives in a different service's listener, changing the flow is risky and finding out what happened means digging through logs.
03You are choosing a style for a new process. Short, simple flows between loosely tied services do fine with choreography. Long or complicated ones are worth an engine.

Tradeoffs

The engine becomes something every flow depends on. It has to be big enough and reliable enough for all of them at once, so keeping it up becomes a platform-wide job.
Choreography's independence is real: no single outage can stop every flow, and teams can ship their own handlers without waiting on anyone.
The process definition is really code. It may look like a config file or a diagram, but it needs versioning, testing, and review just like any other code.

The same move, 1 ways

Every row is a production system that bet on this pattern — the note says how, in that system's own terms.

Netflix
Netflix Technology Blog
2016
The question is whether a multi-service process is coordinated by events each service interprets on its own, or by an engine that owns the process definition and drives the participants. Choreography keeps coupling and central dependencies low, but leaves the process written down nowhere: invisible to query and hard to change. Orchestration makes the process a real, queryable object, at the cost of a central dependency. Netflix draws exactly this contrast in its 'Why not peer to peer choreography?' section. Read the breakdown →

Problems this pattern answers

The walls where its breakdowns live — each opens the cross-company comparison.

Partial completion under crashesNETFLIX →