sydepsystem design atlas

Saga (Choreography)

Each service reacts to the previous event and emits the next, with no central coordinator.

AdvancedDataCommerce
Order ServiceComputeEvent BusMessagingPayment ServiceComputeInventory ServiceCompute

Each participant listens for the event that triggers its step, does its work, and emits its own completion or failure event for the next participant to react to -- avoiding a single orchestrator but spreading the transaction logic across services.

When to use it

  • Participants should stay decoupled and evolve independently, without a shared orchestrator
  • The transaction's steps naturally map to domain events each service already emits

Trade-offs

  • Tracing the full transaction across services requires correlating events end to end
  • Adding a new step means every relevant participant needs updating, not just one orchestrator

Components used

Managed App ServiceEvent Bus

How it works

  • There is no coordinator. Each service listens for the previous step's event, does its work, and emits its own event.
  • Failures are handled by emitting compensating events that earlier participants react to.
  • Services stay loosely coupled and the flow emerges from their reactions rather than from a central definition.

Used in the wild

  • Short flows of two or three steps where a coordinator would be overhead.
  • Organisations wanting maximum team autonomy and minimal shared components.
  • Event-driven systems already built around a broker.

Good to know

  • Beyond roughly four steps the flow becomes very hard to follow, because it exists only as the emergent sum of independent subscriptions. Distributed tracing becomes the only way to see it.
  • Cyclic dependencies are easy to create accidentally — service A's event triggers B, whose event triggers A again — and nothing in the design prevents it.