Process Manager
A component that owns the state and sequencing of a multi-step business process, deciding what happens next in response to events.
The middle position between pure choreography and rigid orchestration, and often the practical answer.
In choreography, each service reacts to events and emits its own. Maximum decoupling, and no single place knows what the process is — which makes failure handling, timeouts and answering "where is order 123?" genuinely hard.
In orchestration, a coordinator calls each service. The process is explicit, at the cost of a component that knows every participant.
A process manager sits between: it subscribes to events rather than calling services synchronously, maintains the state of each process instance, and issues commands when a step is due. The participants stay decoupled from one another; the process becomes explicit and observable.
What it makes possible, and what choreography struggles with: timeouts ("payment not confirmed within 30 minutes — cancel"), compensation sequencing when a saga must unwind, visible state for support and monitoring, and a single place to change the process.
The judgement, per process rather than per system: choreography for simple reactive flows; a process manager for business-critical processes with compensation, deadlines and a state customers ask about. Systems that choose choreography everywhere on principle tend to reconstruct a process manager badly out of status columns and scheduled jobs.