Learning series · 5 episodes · Senior / Staff
When transactions disagree
Five original interview lessons on lost updates, MVCC history, write skew, deadlocks, and serializable retry pressure.
Start series →Follow the decisions in order
- Part 1 of 5
Senior
Both updates succeeded. Why is the counter missing one?Lost update from stale application-calculated assignments under Read Committed, distinguished from atomic SQL arithmetic, compare-and-swap, and short row locking.
- Part 2 of 5
Staff
The reader never blocked the writer. Where did the old row go?Multi-version visibility and snapshot lifetime, distinguishing Read Committed statement snapshots from Repeatable Read transaction snapshots and the vacuum retention cost.
- Part 3 of 5
Staff
Both doctors followed the rule. Why was nobody left on call?Write skew under snapshot isolation, demonstrating a cross-row predicate invariant violated without a write/write conflict and evaluated through guard-row locking or serializable retry.
- Part 4 of 5
Staff
Each transfer holds one row. Why is nothing moving?Real row-lock deadlocks versus ordinary contention, deterministic acquisition ordering, database victim selection and bounded whole-transaction recovery.
- Part 5 of 5
Staff
Serializable fixed the bug. Why did checkout get slower?Serializable Snapshot Isolation conflicts, SQLSTATE 40001, bounded full retries, read-footprint granularity and goodput versus wasted retries under contention.