pattern

Saga Orchestrator

A component that explicitly drives a saga's steps and compensations, holding the flow in one place rather than distributing it across event subscriptions.

sagaorchestrationworkflow

The alternative to choreography, where each service reacts to the previous step's event. The orchestrator issues commands, records progress in durable state, and invokes compensations on failure.

What it buys, and why most non-trivial sagas end up here: the flow exists somewhere you can read it. With choreography the business process is emergent from subscriptions, so nobody can answer "what happens when an order is placed" without tracing events across services. The orchestrator also gives a natural home for timeouts, retries, the saga's current state, and an operator view of stuck instances — all of which choreography leaves you to build separately.

What it costs: a component that knows about every participant, which is coupling of a kind, and a new service to run. The mitigation is that it should know only the sequence and the commands, never the participants' internals.

Implementations range from a state machine in your own service, to durable workflow engines (Temporal, AWS Step Functions, Camunda) that supply persistence, retries, timers and visibility. Building the durable state yourself is the part people underestimate.