Choreography vs Orchestration

The trade is between visibility and coupling, and both options are defensible — which is why the argument recurs.

Orchestration puts one component in charge: it calls each service in turn, holds the process state, decides what happens on failure, and knows what step the process is on. The benefits are large and practical — the flow is readable in one place, the current state of any instance is queryable, compensation logic is centralised, and changing the sequence is a change to one component. The cost is a component that knows about everyone and can become a bottleneck for change.

Choreography has each service publish events and react to others', with no central authority. It is loosely coupled and adding a participant requires changing nothing. The cost is that the process exists nowhere: understanding it requires reading every service, and answering "why is this order stuck" means correlating events across many logs.

The heuristic that holds up in practice: orchestrate business processes, choreograph notifications. A process with defined steps, a completion condition, compensation requirements and an owner who is asked about its status wants an orchestrator. Broadcasting that something happened, so that any number of interested parties can react independently, wants events.

The failure to name: choreography chosen for decoupling, in a flow that is genuinely a business process, produces an implicit distributed workflow that nobody can see, change safely, or debug.