Write Skew
An anomaly where two transactions each read a set of rows, make disjoint writes based on what they read, and together violate an invariant neither could have broken alone.
The classic example: a rule that at least one doctor must be on call. Two doctors each check — concurrently, under snapshot isolation — see that two are on call, and each removes themselves. No row was written twice, so no write conflict is detected, and the invariant is now broken.
It is the anomaly that makes snapshot isolation not serializable, and it is the one most people have never heard of despite snapshot isolation being the default in several major databases (PostgreSQL's REPEATABLE READ, Oracle's SERIALIZABLE, and MySQL's REPEATABLE READ).
Three fixes. Serializable isolation — correct and costs throughput. Materialising the
conflict — write to a row that represents the constraint, so the two transactions do collide.
Explicit locking — SELECT ... FOR UPDATE on the rows the decision depends on.
The architectural lesson: an invariant across several rows is not protected by row-level conflict detection. Any rule of the form "at least one", "no more than N" or "the sum must not exceed" needs this checked deliberately.