Skip to content
hashkey.bond

Archivedistributed-systems

Sagas Trade Atomicity for Compensation

A sequence of local transactions with compensating actions keeps availability and forces you to design for partial failure.

Published
Reading time
1 min read

A saga splits a distributed transaction into local transactions, each with a compensating action. If a step fails, previously completed steps are undone by running their compensations.

The shape

reserve_inventory → charge_card → create_shipment
compensations:     release_card     refund      cancel_shipment

Orchestration (a coordinator decides the steps) is easier to reason about; choreography (events trigger the next step) decouples services but hides the flow.

What changes

  • Isolation is gone: intermediate states are visible. Another transaction can see a reserved-but-not-charged order.
  • Compensations are not rollbacks: they are new business actions that may fail, may be partially applied, and may be observable.
  • Idempotency is mandatory: every step and compensation will be retried.

Design rules

  1. Order steps so the riskiest, least reversible action happens last.
  2. Make each step idempotent with a business key.
  3. Model states explicitly (PENDING, COMPENSATING, FAILED) so operators can intervene.

Takeaway: sagas are a business-process design, not a database feature. If you cannot describe the compensation, the step is not ready.