advanced 2 min answer Multiple choice

An order flow spans several services and cannot use a distributed transaction. What decides between orchestration and choreography for the saga?

sagaorchestrationchoreographycompensationebayarchitecture-selection
Pick one
Show the full answer Hide the answer

The deciding question

For anything with obligations and money attached, someone will ask where an order is and why it has not progressed. Choreography cannot answer it, because no component knows the overall state — reconstructing it means correlating event logs across five services.

Three further consequences follow from the same gap:

  • Timeouts have no owner. If fulfilment never responds, which service notices?
  • Concurrent transitions race. A cancellation arriving while the flow progresses has no arbiter, so both can succeed.
  • Compensation ordering is undefined, because nobody knows how far the flow got.

What the orchestrator provides

An authoritative current state, a natural home for timeouts each with a defined action, one place where the sequence is defined so changing it is one change, and enforcement that only one transition applies at a time.

What it costs

A central component every flow passes through — a new operational dependency and a change bottleneck if it accumulates logic that belongs in services. Keep it to sequencing, timeouts and compensation, not business rules, or it becomes a distributed monolith every team must change and nobody owns.

Where choreography is right

Notifications: "order shipped" consumed by analytics, search, email and marketing. The publisher does not care who listens, consumers are added freely, and a failure delays only that consumer's work.

The rule: orchestrate obligations, choreograph notifications.

The details that decide whether it works in production

  • Idempotency keys on every command, because at-least-once delivery means every step reruns occasionally.
  • An explicit timeout with a defined action on every wait state.
  • Compensation modelled as a forward business action, not a rollback — a refund is payment_refunded, a distinct state with accounting consequences and customer communication, not the absence of a charge.
  • A "compensation failed, human required" state, since a refund can itself fail and retrying forever in silence is worse.
  • A reconciliation job against payment and fulfilment records, because in a system this asynchronous drift is a certainty.