Orchestration

Orchestration coordinates a workflow through an explicit controller that knows the steps, waits for replies or events, tracks state, and decides what to do next. Instead of process logic being spread across many reacting services, one orchestrator component becomes the place where the workflow is visible.

This does not mean the orchestrator performs every business action itself. The participating services still own their local transactions. The orchestrator owns process control: when to request inventory reservation, when to ask for payment authorization, when to move to shipment creation, and what to do when a step times out or fails.

    sequenceDiagram
	    participant O as Orchestrator
	    participant I as Inventory
	    participant P as Payment
	    participant S as Shipping
	
	    O->>I: reserve inventory
	    I-->>O: inventory reserved
	    O->>P: authorize payment
	    P-->>O: payment authorized
	    O->>S: create shipment
	    S-->>O: shipment created

What to notice:

• one component owns process flow explicitly
• participating services still own their local work
• timeouts, retries, and branching become visible in one workflow model

Why Teams Choose Orchestration

Orchestration is usually chosen because visibility matters. For business-critical or branched workflows, it is often valuable to have one place that answers:

• what step the process is currently on
• what has already succeeded
• what still needs to happen
• what timeout applies
• what compensation or fallback should occur next

This makes orchestration attractive for order fulfillment, loan processing, claims handling, compliance workflows, and other processes where business stakeholders need traceability as much as engineers do.

The Orchestrator Owns Process State

An orchestrator usually maintains workflow state explicitly. That can include:

• current step
• completed steps
• correlation IDs for downstream requests
• timeout deadlines
• compensation status

1workflowState:
2  workflowId: wf_401
3  type: order-fulfillment
4  status: waiting_for_payment
5  completedSteps:
6    - inventory_reserved
7  nextAction: authorize_payment
8  timeoutAt: 2026-03-23T17:00:00Z

This state model is one of orchestration’s main strengths. It turns a hidden event chain into a visible process record.

The Centralization Trade-Off

Orchestration is not free. The orchestrator can become:

• a control bottleneck
• a “god service” that knows too much domain detail
• a place where too many unrelated workflows accumulate
• a single mental dependency for every process change

This is why good orchestration still preserves domain boundaries. The orchestrator should coordinate local actions, not absorb the business logic of every participating service.

Commands, Events, and Replies

In orchestrated systems, the orchestrator often sends commands or request messages and then waits for replies or events. This means the design should be explicit about:

• correlation IDs
• expected replies
• timeout rules
• duplicate or late replies
• idempotent re-issuance of steps where needed

 1{
 2  "commandName": "payment.authorize",
 3  "workflowId": "wf_401",
 4  "correlationId": "ord_441",
 5  "replyTo": "workflow-replies",
 6  "data": {
 7    "orderId": "ord_441",
 8    "amount": 180.0
 9  }
10}

The orchestrator is strongest when these control contracts are deliberate and observable.

Common Mistakes

• putting too much domain decision logic into one orchestrator until it becomes a god-service
• using one orchestration engine for unrelated workflows with very different lifecycles
• failing to persist enough workflow state for recovery and operator visibility
• assuming central visibility removes the need for idempotent local participants
• confusing workflow coordination with direct ownership of every business rule

Design Review Question

A team proposes a single “business-process-service” that will orchestrate orders, refunds, onboarding, and compliance escalations because it is easier to operate one controller. What should you challenge?

Challenge the scope and cohesion of the orchestrator. One controller for many unrelated processes often becomes a central dependency with too much domain knowledge. The stronger design is usually one orchestrator per workflow family or bounded process area, with explicit ownership and narrower responsibilities.

Quiz Time