Two concurrent transactions running under snapshot isolation both read the same inventory row and both issue an update to it. Describe exactly what the database does, what error the loser sees, and which classic anomaly this rule does and does not prevent.

## The rule Snapshot isolation is defined by two halves. The read half: a transaction sees the database as of its start. The write half: **two concurrent transactions may not both modify the same data item**. "Concurrent" means their execution intervals overlap — specifically, the other transaction committed after this transaction's snapshot was taken. Without the write half, both transactions would read from their own snapshots and blindly overwrite each other, and the update that landed first would vanish with no trace. ## Two implementations of the same rule **First-committer-wins** is the abstract formulation. Both transactions update their own private versions of the row. At commit time the engine checks whether any *other* transaction committed a write to the same row since this transaction's snapshot was taken. If so, this transaction aborts. Whoever commits first is the winner purely by timing; the second one's work is discarded. **First-updater-wins** is what most MVCC engines actually do, because it avoids doing work that will be thrown away. When a transaction issues the UPDATE it takes an exclusive row lock. If another live transaction already holds it, the second transaction *blocks* — this is the one place snapshot isolation makes a writer wait. When the holder finishes, the waiter checks the outcome: if the holder committed, the waiter aborts with a serialization failure, because the row it is about to overwrite has changed under its snapshot; if the holder rolled back, no committed change happened and the waiter proceeds. The observable difference is *when* you learn you lost and whether you burned CPU first. The correctness outcome is identical: at most one of the two concurrent updates to a row survives, and the loser is told. ## The error the loser sees A serialization failure — a distinct error class from constraint violations, deadlocks, or timeouts, and one whose contract is *this transaction can succeed if you run it again*. That contract matters because the correct handling is a bounded retry with backoff at the transaction boundary, which re-runs the reads against a new snapshot. A retry that reuses values read before the abort defeats the purpose entirely: the whole point is that the winner's value must now be observed. Do not confuse this with a deadlock. A deadlock is a cycle of waits that the engine breaks by choosing a victim; a snapshot-isolation write conflict is a unilateral abort caused by an update whose basis has changed. Both are retryable, but they have different causes and different fixes. ## What this prevents: lost update Lost update is the read-modify-write race. Both transactions read `stock = 10`, both compute `10 - 1`, both write `9`, and two units were sold while inventory only dropped by one. Under read committed *without* extra care this is a real risk, because the second write is simply an overwrite of a row the transaction read earlier at a value that has since changed. Snapshot isolation's write-write rule closes it: the second transaction aborts, and on retry it reads `9` and writes `8`. It is worth naming the alternative fixes, because interviewers probe them. An atomic in-place update (`SET stock = stock - 1`) avoids the round trip entirely and is safe even at weaker levels, since the engine re-reads the current row under lock. An explicit locking read taken before the computation serializes the pair by blocking. A compare-and-set update that includes the previously read version in its predicate detects the loss by affecting zero rows. Snapshot isolation gives you the guarantee automatically, at the price of an abort you must handle. ## What this does not prevent: write skew The write-write rule is about a *single* data item. It says nothing when two transactions read overlapping data and write **different** rows: no item is written twice, so no conflict is detected and both commit. That is write skew, and it is exactly why snapshot isolation is not serializable. Candidates who say "first-committer-wins makes SI safe" have collapsed the two cases; the correct framing is that SI validates the *write* set and never validates the *read* set. ## Practical consequences First, hot rows produce abort or block storms. A single counter row updated by every request turns the write-write rule into a throughput ceiling, and the fix is to spread the contention (sharded counters, aggregate on read, or move the counter out of the transaction) rather than to weaken isolation. Second, the abort rate is proportional to transaction length times contention, so long transactions that touch popular rows are the usual culprit in a conflict-heavy system. Third, whichever implementation your engine uses, the application-side contract is the same: catch serialization failures at the transaction boundary and retry the whole unit of work.