Pattern · seen in 1 breakdown across 1 company

Choreography vs Orchestration

Definition

Two ways to coordinate a multi-service process: choreography, where each service consumes events and emits the next with no component owning the whole, and orchestration, where an engine owns the process definition and drives participants through it. Choreography minimizes coupling and central dependencies — there is nothing shared to operate or to fail — but the process itself is unrepresented: it exists only as an emergent property of queues and handlers, invisible to query, hard to change, and impossible to enumerate when it stalls. Orchestration makes the process a first-class object — definable, queryable, resumable — at the price of a central engine on which every flow now depends.

Boundary against Embedded vs Centralized Orchestration: that pattern assumes an engine exists and asks where it lives (inside the service or as a platform); this one asks whether the process has an owner at all. A system usually crosses this boundary first — from choreography to some orchestrator — before the embedded-vs-centralized question arises.

When it applies

01Multi-step, multi-service business processes — especially long-running ones where stalls are routine and 'what remains?' must be answerable

02Flows whose logic is currently smeared across pub/sub consumers, making change risky and visibility forensic

03Choosing coordination style for a new domain: simple, short, loosely coupled flows tolerate choreography; complex or long-lived ones repay an engine

Tradeoffs

Orchestration's engine is a shared operational dependency sized for every flow at once — availability and scale become platform problems

Choreography's decoupling is real: no engine outage can stop all flows, and teams ship handlers without central coordination

The blueprint or definition language becomes a program in data's clothing — versioning, testing, and review discipline move to the definition layer

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

Whether a multi-service process is coordinated by events each service interprets locally, or by an engine that owns the process definition and drives participants. Choreography minimizes coupling and central dependencies but leaves the process unrepresented — invisible to query, hard to change. Orchestration makes the process a first-class object at the cost of a central dependency. First mint, from the post's own '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 →