sydepsystem design atlas

Saga (Orchestration)

A central orchestrator drives a multi-step transaction and its compensations.

AdvancedDataCommerce
Saga OrchestratorComputePayment ServiceComputeInventory ServiceComputeShipping ServiceCompute

An orchestrator explicitly calls each participant in sequence for a long-running business transaction (e.g. book flight, then hotel, then car) and calls compensating actions on any participant already completed if a later step fails.

When to use it

  • A business transaction spans multiple services with no shared database transaction
  • You want the transaction's logic and failure handling centralised and easy to reason about

Trade-offs

  • The orchestrator becomes a critical, stateful component that must itself be reliable
  • Every participant needs a well-defined compensating action, not just a forward action

Components used

Workflow OrchestratorManaged App Service

How it works

  • A central orchestrator explicitly drives each step of a multi-service transaction, calling participants in order.
  • If a step fails, the orchestrator invokes compensating actions to semantically undo the completed steps in reverse.
  • The workflow is defined in one place, so the overall business process is readable and its state is inspectable.

Used in the wild

  • Order fulfilment spanning payment, inventory and shipping.
  • Account opening with identity, credit and provisioning steps.
  • Any long-running process needing visibility into where each instance currently sits.

Good to know

  • Compensation is not rollback. You cannot un-send an email or un-charge a card without a trace — you send an apology and issue a refund, and both are visible to the customer.
  • Sagas provide no isolation, so other transactions observe intermediate states. Semantic locks or status flags are needed to stop someone acting on a half-finished order.