A saga has already completed step 1 (reserve inventory) and step 2 (charge payment) while step 3 (arrange shipping) is still pending. Another transaction reads the order in this intermediate state. What consistency problem does this create, and how does the 'semantic lock' technique help address it?

## One of a family of countermeasures **Semantic locking** is one of a family of countermeasures originally described for handling the isolation anomalies that sagas inherently create, and it's the most commonly used one in practice. Alongside it: - commutative updates, - pessimistic view, - reread value, - version files, - by value. ## Why the technique is needed To see why it's needed, recall that a saga is a sequence of independently-committed local transactions, with no cross-service lock held between steps - that's exactly what gives sagas their availability advantage over two-phase commit. The consequence is that between step 1 committing and the saga's final step committing, the record(s) touched by step 1 are in a normal, fully-committed, publicly-visible state as far as any other transaction in the system is concerned - there's nothing marking them as 'not really done yet.' If an order record has its inventory decremented by step 1 but the saga's payment step hasn't run yet, a completely unrelated transaction - a warehouse report, a different saga, a customer's own order-status page - can read that record and see 'inventory reserved,' with no signal that the reservation might still be undone by a compensation a moment later. The anomalies this creates: - **dirty read** - this is a dirty read in the classical database sense; - **lost updates** - sagas are also vulnerable to two sagas concurrently modifying overlapping data, where the second saga's write overwrites the first's without knowing about it; - **non-repeatable reads** - reading the same record twice within one logical operation and getting different answers because a saga committed a step in between. ## How the marker works A semantic lock addresses this by having the application, not the database engine, add an explicit marker to the record while it's mid-saga. Typically this is a status field on the record - `PENDING`, `RESERVING`, `IN_SAGA` - sometimes combined with the ID of the saga instance that owns the lock, set as part of the same local transaction that makes the change. Any other code path that reads this record is expected, by convention and by explicit checks in the business logic, to treat a locked record differently. It might: - refuse to let another saga touch the same record until the lock clears; - queue its own operation until the status changes; - show the customer 'processing' instead of a final order state; - or in some designs actively trigger compensation of an earlier conflicting saga to release the lock faster. ## Why the word is 'semantic' The word 'semantic' signals precisely that this is not a real database lock - no row-level lock is held, no other transaction is physically blocked from reading or even writing the row if it doesn't check the status field. The entire mechanism depends on every piece of code that touches this data agreeing to check and honor the flag; it's a convention enforced by discipline and code review, not by the database, which is both its main strength (cheap, doesn't hold real locks, doesn't block availability) and its main weakness (a single forgotten check anywhere in the codebase silently defeats it). ## The cost side The cost side of this trade-off is real. - You now have extra state to design, migrate, and reason about - every record touched by a saga needs a status field and the business logic to interpret it correctly in every context that reads it, which is easy to get partially right and miss an edge case (a new report added six months later that queries the table directly and doesn't know to filter out `PENDING` rows, for instance). - There's also the **orphaned-lock** problem: if the saga that set the lock crashes or gets stuck, the record can be left semantically locked forever unless there's a separate timeout or reconciliation job that detects stale locks and either resumes or force-clears them - which itself needs careful design so it doesn't clear a lock for a saga that's actually still legitimately in progress, just slow. ## A concrete example A concrete example: in an inventory-reservation saga, the moment stock is decremented, the product record is marked with a reservation status and the owning order ID; the product listing page and other checkout flows are written to treat that status as 'unavailable' rather than silently showing (or worse, allowing purchase of) inventory that's provisionally spoken for but not yet guaranteed. If the payment step later fails and the saga compensates by releasing the stock, the status flips back to available. This is a very common real pattern in e-commerce and ticketing systems (seat-hold timers on ticketing platforms are functionally the same idea - a semantic lock with a built-in expiry), and it's worth knowing by name specifically because interviewers use it to check whether a candidate understands that saga isolation problems are real and need an explicit, named countermeasure, rather than being hand-waved away as 'eventually consistent, so it's fine.'