Orchestrator Pattern: Coordinating Multi-Step Workflows

A customer places an order. Inventory is reserved, payment is authorized, shipping is created, and the order is marked complete.

Coordination becomes harder when only part of that sequence succeeds.

Reserve inventory   ✓
Authorize payment   ✓
Create shipment     ✗

The orchestrator pattern gives the workflow a coordinator that knows which steps have completed and what should happen next.

The Orchestrator Owns Coordination

A simple order workflow might be:

Create Order
    ↓
Reserve Inventory
    ↓
Authorize Payment
    ↓
Create Shipment
    ↓
Complete Order

Inventory still owns inventory rules. Payment still owns payment rules. Shipping still owns fulfilment. The orchestrator owns the sequence connecting them.

It can persist explicit workflow state:

CREATED
  ↓
INVENTORY_RESERVED
  ↓
PAYMENT_AUTHORIZED
  ↓
SHIPMENT_CREATED
  ↓
COMPLETED

Durable state matters when a workflow lasts longer than one process or request. If the coordinator restarts, it needs to recover where the workflow was rather than blindly starting from the beginning.

Retries Need Idempotency

Suppose the shipping call times out.

A timeout does not prove that shipping failed. The service may have created the shipment and lost the response on the way back.

request sent
    ↓
shipment created
    ↓
response lost
    ↓
orchestrator sees timeout

Repeating the request without protection could create a second shipment.

Orchestrated workflows therefore commonly use idempotent operations or idempotency keys. A retry carries the same operation identifier, allowing the receiving service to recognize work that has already succeeded.

Retry policy also needs limits and backoff. A permanent validation error should not be retried like a transient network failure.

Compensation Handles Partial Success

Some completed work cannot be rolled back as if it never happened.

If shipping rejects an unsupported destination after inventory and payment have succeeded, the workflow may compensate:

Reserve Inventory       ✓
Authorize Payment       ✓
Create Shipment         ✗
        ↓
Cancel Authorization
        ↓
Release Inventory
        ↓
Cancel Order

A compensation is a business action, not necessarily a database rollback. A settled payment may require a refund. An email cannot be unsent. Physical fulfilment may require a return or another warehouse operation.

This is the same recovery model used by saga-style distributed transactions.

Durable State Has Failure Windows Too

Persisted workflow state still has failure windows.

Consider:

payment succeeds
      ↓
orchestrator crashes
      ↓
"payment succeeded" state was not recorded

After restart, the coordinator needs a safe way to determine whether payment happened.

Idempotency, durable event histories, correlation identifiers, reconciliation, and workflow-engine guarantees can reduce these ambiguous windows. The exact mechanism depends on the implementation.

A durable orchestrator should be designed around the possibility that its own process will fail between any two operations.

Central Coordination Makes Progress Visible

Because the coordinator tracks the workflow, it can expose a useful operational history:

Order 1843

10:02  Inventory reserved
10:03  Payment authorized
10:03  Shipping failed
10:04  Shipping retry failed
10:06  Shipping succeeded
10:06  Order completed

That record helps answer practical questions: where is the order, which step failed, how many retries occurred, and whether support can safely resume the process.

Distributed tracing and service logs still matter, but the workflow record describes business progress directly.

Keep Business Logic in the Services

An orchestrator can become a problem when it turns into a large central service containing everyone else’s rules.

The coordinator should know things such as:

after inventory → request payment
after payment   → request shipping
shipping retry exhausted → compensate

It should not become the implementation of inventory allocation, payment authorization, or shipping-rate calculation.

Keeping that boundary preserves service ownership while centralizing only the workflow.

Orchestration and Choreography Put Coordination in Different Places

In choreography, services react to events rather than following commands from one workflow controller.

OrderCreated
   ↓
InventoryReserved
   ↓
PaymentAuthorized
   ↓
ShipmentCreated

This can work well when reactions are independent and the overall process does not need one explicit owner.

As a process gains branches, deadlines, compensation, manual approvals, and support requirements, distributed workflow logic becomes harder to inspect. Orchestration makes that logic explicit at the cost of introducing a coordinator.

Many systems use both: orchestration for a critical stateful transaction and events for independent downstream reactions.

The Workflow Needs a Defined Outcome

A successful workflow might end at COMPLETED. A failed order can also have a valid workflow outcome:

PAYMENT_FAILED
     ↓
INVENTORY_RELEASED
     ↓
CANCELLED

The business operation did not succeed, but the coordinator brought the system to a known state.

That is the practical value of the orchestrator pattern. It gives a multi-step process one place to track progress, decide the next action, and recover from partial success.