Saga Pattern Choreography and Orchestration Lab (Interactive)
Run a four-service order saga, fail step three, and unwind it with compensating transactions. Execute Order-Payment-Inventory-Shipping as local transactions either way coordinated, then compare bus messages, compensations run, and exposed intermediate states.
Saga Rollback Lab
A multi-service order spans four local transactions. Pick the coordination style and inject a failure — the saga undoes work with compensating transactions, not a rollback.
Orders
T1 create order
C1 cancel order
waiting
Payments
T2 charge card
C2 refund card
waiting
Inventory
T3 reserve stock
C3 release stock
waiting
Shipping
T4 book pickup
C4 cancel pickup
waiting
- Bus messages
- 0
- Compensations run
- 0
- Exposed intermediate states
- 0
- Phase
- idle
Orchestration hides routing in one coordinator (command + ack per step) so the rollback plan is explicit; choreography removes the coordinator (one event per step) but every compensation listener must know its upstream — hidden cycles like Payment → Ship → Payment will deadlock it. Both styles need idempotent T and C steps because messages are at-least-once.
- Press “Step saga” to run one local transaction (or compensation) per click.
No global rollback exists across services: C1–C4 must be semantic inverses, and readers can see the “paid but not shipped” window — sagas trade isolation for availability.
How It Works Under the Hood
A business transaction spanning services cannot use 2PC, so the Saga pattern commits one local transaction per step and undoes the past with written-in-advance compensating transactions when a later step fails. Orchestration centralizes the state machine in a coordinator that commands each service — explicit rollback, one place to see progress — while choreography lets each service react to events, removing the coordinator but scattering the workflow across listeners until cycles lurk in plain sight. This lab runs either style step by step, injects a failing participant, and measures message cost and the dirty “paid but not shipped” window readers see mid-flight.
Core Architectural Principles
- Reverse compensation order C1…Ck after a failure, since no global rollback exists.
- Orchestration pays two messages per step but owns the rollback plan explicitly.
- Choreography publishes one event per step yet hides cycles and complicates compensation routing.
Pick a saga style out loud with reasons: “orchestration for the order flow because the state machine is complex and we need visibility; choreography for simple notify-style flows.” Then cover idempotent T and C steps, compensation semantics, and that readers see intermediate states — sagas sacrifice isolation.
Sagas keep services autonomous and databases decoupled but trade ACID isolation for eventual business consistency.