Because a saga is a sequence of independently committing local transactions rather than one ACID transaction, other operations can observe and act on data mid-saga. What isolation anomalies does this create, and what techniques mitigate them without resorting to a distributed lock?

## Why a saga gives up isolation A single ACID transaction gives you Isolation as one of its four guarantees: concurrent transactions can't observe each other's uncommitted intermediate state, and the database enforces this with locks or MVCC snapshots under the hood. A saga deliberately gives this up — it exists specifically because holding those locks across service boundaries (which is what 2PC would require) is unacceptable for availability. The consequence is that between the commit of saga step 2 and the commit of saga step 3, the effects of step 2 are fully durable and visible to every other transaction in the system, including transactions that have nothing to do with this saga, for as long as the saga takes to either finish or compensate. ## The classic anomalies This produces classic anomalies from the original sagas literature, applied here in a microservices context. - **A lost update** happens when two concurrent operations both read a value before either writes, and one write clobbers the other; in a saga context this shows up when, say, an inventory saga step and an unrelated direct-purchase transaction both read `available_quantity = 10` before either commits its change, and whichever commits second silently discards the other's decrement, leaving the counter wrong by the lost amount. - **A dirty read** happens when a transaction reads data that a saga step wrote but that step is later compensated away — for example, a loyalty-points balance that a saga step incremented gets read and spent by the customer in a completely different transaction, and moments later the saga fails and compensates by decrementing the points back, leaving the balance negative or inconsistent relative to what was actually spent. - **A non-repeatable (fuzzy) read** is when a saga itself reads the same aggregate at two different steps and gets two different answers because an unrelated transaction modified it in between — a discount-eligibility check at step one says "eligible," but by a later step a concurrent transaction has already consumed the customer's one-time discount, and the saga proceeds on stale information. ## Why the naive fix is worse The naive fix — take out a database lock and hold it across the whole saga — reintroduces exactly the coupling and blocking problem sagas were adopted to avoid; it's effectively hand-rolled 2PC and defeats the purpose. The established mitigations instead work at the application/business level. ## The mitigations 1. **Semantic lock**: mark the record with an explicit status flag (e.g., a `PENDING` or `RESERVED` state on the row) the moment a saga step touches it. Other transactions are written to check this flag and respond accordingly — refuse the operation, queue it, or route it through a compensating-aware path — rather than the database silently allowing an unaware read or write to interleave. This is "semantic" because it's enforced by application logic reading and respecting a business field, not by the database's native locking machinery, so it doesn't hold a real lock or block other unrelated work. 2. **Commutative updates**: design the operations themselves so that the order they're applied in doesn't matter to the final result — "increment balance by N" and "decrement balance by N" commute regardless of interleaving, unlike "set balance = X" which requires knowing the current value and can silently lose an update if two set operations race. Where you can express saga effects as commutative deltas rather than absolute overwrites, lost updates stop being possible by construction. 3. **Pessimistic view**: for reads that must not observe an in-flight saga's intermediate state, route them through a check that recognizes a semantic-locked record and returns a controlled "not currently available" response (or blocks/queues briefly) rather than returning a value that might be compensated away moments later. This trades a slightly worse UX (a temporary "please retry" for a record mid-saga) for avoiding a dirty read of state that's not yet final. 4. **Reordering and step design**: place operations vulnerable to fuzzy reads (like discount-eligibility checks) as late in the saga as practically possible, ideally re-validated right before the point of no return, rather than trusting a check performed several steps and network round-trips earlier. ## Why these are only partial These are genuinely partial mitigations, not a full restoration of isolation — they reduce the frequency and blast radius of anomalies for the specific fields you've thought to protect, but a saga fundamentally cannot offer the blanket guarantee a single ACID transaction does, and teams need to explicitly decide, per field, whether the business impact of a possible anomaly (an over-sold item, a double-spent discount) is tolerable or needs one of these mitigations. In practice, most teams apply semantic locks only to a small number of high-value fields — inventory counts, account balances, one-time discount flags — rather than trying to protect every field a saga touches, because the engineering cost of full protection everywhere would erode most of the availability benefit the saga was adopted for in the first place.