Saga Isolation Anomaly
The intermediate states visible to other transactions during a saga, because a saga provides atomicity and durability but not isolation.
A saga replaces a distributed transaction with a sequence of local transactions and compensations. It gives atomicity in the sense that the sequence either completes or is compensated — but each local transaction commits immediately, so its effects are visible before the saga finishes.
The anomalies this produces have names worth knowing: lost updates, where another transaction overwrites a saga's uncommitted-in-spirit change; dirty reads, where another process acts on a state that will later be compensated; and fuzzy reads, where a value changes mid-saga.
The countermeasures, which must be chosen deliberately:
Semantic lock — a status field marking the record as in-progress, so other processes can decline to act on it. The most common approach.
Commutative updates — operations whose order does not matter, such as increments, so interleaving is harmless.
Pessimistic ordering — sequencing steps so the most damaging anomaly cannot occur, for instance debiting before crediting.
Re-read and validate before the compensating action.
The design point people miss: compensation is not rollback. A refund is not the erasure of a charge — it is a new business event, visible to the customer, and sometimes not fully reversible. Where an action cannot be compensated, it must be sequenced last.