Payment failed after inventory was reserved. Walk me through the compensation.
“In an order saga, the payment step fails after inventory has been reserved. What runs, what state does the user see, and what can go wrong during compensation itself?”
What this tests
- Compensation as semantic undo, not rollback
- Persisted saga state and idempotent, retryable compensations
- Handling failures of the compensation itself
- Orchestration vs choreography for this flow
Answers by level
Read the beginner answer first and notice what is missing.
The saga has done Create Order and Reserve Inventory; Charge Payment failed. Compensation runs the undo steps in reverse order: Release Inventory, then Cancel Order. These are new forward transactions that semantically reverse the effect — the reservation row is marked released, not deleted, and the order moves to cancelled with a reason, not back to nonexistence. The user sees pending during the saga and payment failed at the end; they never see an order that briefly existed and vanished.
Compensation can fail too: the inventory service may be down. So the saga state (step 2 done, compensating step 2) is persisted, and the compensation is retried with backoff; it must be idempotent because retries will re-run it. If it keeps failing, the saga parks in a compensation failed state that is alerted and resolved by a person — you never leave a silently half-compensated order.
Green flags · Red flags
- Reverse-order semantic undo, with state history preserved
- Persisted saga state; compensations are retried and idempotent
- Handles "compensation failed" explicitly with alerting
- Distinguishes timeout (unknown) from failure (known)
- Places non-compensatable steps at the end
- "Compensation just rolls the transaction back."
- Deletes rows during compensation and loses the audit trail
- Retries compensation in a loop with no terminal failure state
- Treats a payment timeout as a payment failure