Orchestration and Choreography

Orchestration and choreography are forms of coordination distinguished primarily by where control of a coherent process resides.

Both forms can have a shared goal, global protocol, process boundary, and durable state. At that boundary, process control flow constrains which steps may follow, while orchestration and choreography describe where the authority to interpret process state, select or enable successors, observe progress, and authorize completion or recovery is placed.

The distinction is a spectrum rather than one binary switch. Its dimensions include whether one role owns process state, who decides next steps, who observes progress, who authorizes completion, and which protocol rules constrain participant behavior. It is orthogonal to process-flow direction, interaction-control roles, callback shape, and runtime scheduling. Those mechanisms determine how participants become active and receive execution opportunity; orchestration and choreography determine how process authority and progress interpretation are distributed.

Orchestration

Orchestration coordinates a process through an explicit process manager. One logical role owns process execution state, decides next steps, directs participants, observes enough replies or events to advance, and handles timeout, retry, cancellation, compensation, or completion.

The physical node holding the role may change across leases, failover, restarts, or durable execution recovery. The design remains orchestrated when one logical process manager controls the run.

Examples include:

A saga orchestrator that sends commands and compensating commands to participants.
A durable workflow that records workflow history, schedules activities, observes signals, and resumes after host failure.
An index rebuild coordinator that tracks partitions, assigns ranges to workers, monitors progress, retries failed work, and decides completion.
A CI pipeline controller that schedules jobs, waits for results, applies dependencies, and marks the run failed or complete.
A human approval workflow that records pending approvals, sends reminders, handles expiry, and escalates exceptions.

Choreography

Choreography coordinates a process without one explicit process manager controlling the whole execution. Process-control responsibility is distributed across participants following local rules over shared messages, events, logs, topics, membership state, or protocols. Their compatible local transitions compose into coherent global process behavior.

Choreography does not mean there is no process, control structure, or global protocol. The global protocol may be explicit or implicit in aligned configurations, topic contracts, schemas, command/event meanings, subscription rules, quorum rules, or shared state-machine specifications. It is a logical control structure rather than an operational controller: no single node necessarily owns the complete execution state, observes global progress, commands every participant, or decides completion.

Examples include:

Event-driven order fulfillment where payment, inventory, shipping, notification, and projection services react to published events and local state.
Pub/sub projection pipelines where consumers independently follow committed event streams and update their own read models.
Gossip protocols where peers exchange local observations and converge without a central coordinator.
Population protocols where anonymous finite-state agents update through pairwise local transition rules and eventually converge under a fairness assumption.
CRDT replication where replicas accept compatible local updates and merge by algebraic rules.
Domain event choreography where each participant owns its own transition and emits events for others to interpret.

Cross-Realm Process Control

The same semantic process is present at both ends of the spectrum. In cross-realm projection, the semantic process and its global protocol are arranged as participant roles, interactions, and process structure in the system graph, and those participant structures are then lowered through realization into runtime mechanisms.

In choreography, the global protocol restricts to participant-local rules. Compatible local behaviors must agree on their shared interactions and glue into a coherent global run. The global process may therefore be drawn as a logical node with projection or conformance edges to every participant, but those are typed correspondence edges rather than command, scheduling, or runtime-control edges. No participant realizes that global node as an active controller.

In orchestration, a substantial part of the global control structure is additionally allocated to a process manager. The manager becomes an active observer with process identity, execution state, next-step authority, and completion or recovery responsibility. Other participants still retain their own transition authority and may constrain which manager requests they accept.

Cross-realm process control in choreography and orchestration

Choreography distributes process control through role projection and compatible local behavior; orchestration realizes more of the global control structure in an active process manager. Both system-graph shapes lower independently into replaceable runtime mechanisms.

The variance of these mappings depends on the chosen objects and arrow direction. Global-to-local role projection often behaves as contravariant restriction with respect to context inclusion; compatible local behavior glues in the reverse local-to-global direction. Participant-to-substrate lowering is commonly covariant when it preserves identities and composition, while provided and required ports and their interface roles may introduce mixed variance. Functoriality therefore requires every mapping to name its source, target, preserved structure, and direction rather than calling every cross-realm relation merely a projection.

Coordination Spectrum

The spectrum is more useful when decomposed into comparison properties:

Property	More choreographed	Mixed or leader-mediated	More orchestrated
Process description	Global protocol, shared rule set, or compatible local rules.	Global protocol with differentiated roles.	Executable process owned by one logical process manager.
Control role	No participant controls the whole run.	A leader, proposer, coordinator, or primary controls a phase or proposal path.	One logical role directs the run from start to completion.
Process state	Distributed across participant state, shared logs, local observations, or convergence behavior.	Split between leader state and durable participant or quorum state.	Explicit process record, workflow history, checkpoint, or command log.
Next-step authority	Local transition rules and available interactions determine progress.	A leader proposes next work, but protocol rules constrain acceptance.	The process manager chooses and issues next commands or effects.
Progress observation	No single participant necessarily sees global progress.	Progress is observed through quorums, leases, acknowledgments, or replicated metadata.	The process manager observes enough replies, events, and timers to advance.
Completion meaning	Stable convergence, local output agreement, merge fixpoint, or protocol-defined global condition.	Quorum decision, replicated-log commit, atomic-commit decision, or view-specific completion.	Explicit completion, rejection, compensation, timeout, or escalation by the process manager.
Failure handling	Fairness, retry, merge, local protocol rules, or eventual convergence.	Election, ballot/view change, durable participant metadata, quorum recovery.	Durable process recovery, retries, compensations, deadlines, and escalation.
Typical examples	Population protocols, gossip, CRDT replication, event choreography.	Paxos, Multi-Paxos, Raft, Zab, Viewstamped Replication, two-phase commit.	saga orchestrators, durable workflows, index rebuild coordinators, CI pipeline controllers.

This table should not be read as a ranking. It identifies where control and authority reside for a given process boundary. A system can be choreographed on one axis and orchestrated on another.

Middle Ground

Many distributed protocols sit between pure choreography and classic orchestration.

Population protocols sit near the choreographed end of the spectrum. The protocol has a global semantic objective and a shared transition rule, but no agent owns process identity, observes global progress, commands another agent, or decides completion. The scheduler or adversary supplies interaction opportunities under a fairness assumption; it is part of the execution environment, not a process manager in the protocol. If an implementation added a central scheduler that inspected global state and chose interactions to drive a result, that implementation would add orchestration outside the basic population-protocol model.

Paxos can be seen as more choreographed than an index rebuild. Paxos implements a single replicated state machine and coordinates participants toward a shared decision, but no single node "runs the algorithm" in the way an index rebuild coordinator runs a rebuild. Proposers, acceptors, and learners follow protocol-local rules. A leader or proposer may coordinate a round and make global proposals, but it cannot unilaterally authorize the history; quorum intersection and acceptor state determine which value is chosen. The leader role can change, and the authority to decide is distributed through the protocol.

An index rebuild may also have a leader that changes across runs or after restart. It is still more orchestrated when one logical process manager records execution state, assigns work to workers, directly observes their progress, retries failed work, and decides completion for the rebuild process.

Consensus protocols such as Paxos, Multi-Paxos, Raft, Zab, and Viewstamped Replication often use leader-mediated choreography: a leader coordinates proposals, but correctness is constrained by distributed participant rules, quorum state, durable metadata, and recovery behavior.

Two-phase commit has a stronger coordinator shape than Paxos because one coordinator drives prepare and commit or abort for a fixed transaction boundary. It is still a narrow atomic-commit protocol, not a general process manager for the business process around the transaction.

Design Questions

When classifying a process, ask:

Where does process execution state live?
Which role decides the next step?
Which role observes progress or failure?
Are participants commanded by a process manager, or do they follow local protocol rules?
Is the scheduler, broker, network, or interaction pattern an environment assumption or a semantic controller?
Is authority centralized, leader-mediated, quorum-mediated, or distributed?
Can the controller role change without changing the process identity?
Which state is durable enough to recover the process?