Saga Pattern for Order Fulfillment

Choreography vs orchestration — why we picked orchestrated sagas with compensating transactions.

Distributed transactions with 2PC was not an option across payment, inventory, and shipping services.

Flow

sequenceDiagram
  participant O as Order Service
  participant P as Payment
  participant I as Inventory
  participant S as Shipping

  O->>P: Reserve payment
  P-->>O: OK
  O->>I: Reserve stock
  I-->>O: Fail
  O->>P: Compensate (release)

Orchestration vs Choreography

Approach	Pros	Cons
Choreography (events only)	Loose coupling	Hard to trace, debug
Orchestration (central coordinator)	Clear state machine	Single point to maintain

We chose orchestration with state persisted in PostgreSQL. Each step idempotent. Compensating actions explicit in the saga definition — no “hope the event handler reverses it.”

Saga timeout: 15 minutes. Stuck sagas alert to on-call.

saga , distributed-transactions , orders · .NET , PostgreSQL , Redis

Flow

Orchestration vs Choreography

More in Distributed Systems