Build fluency in the vocabulary of letting readers see a consistent snapshot without blocking on concurrent writers.
0 / 5 completed
1 / 5
A teammate explains that a database lets a long-running read transaction see a consistent snapshot of every row as it existed at the transaction's start, even while other transactions concurrently write new versions of those rows, without the reader ever blocking on a writer's lock. What concurrency-control technique is being described?
Multi-version concurrency control, or MVCC, is exactly this: the database keeps multiple versions of each row, and a transaction reads the version consistent with its own snapshot timestamp, so a long-running reader sees a stable view of the data as it existed when the transaction started, even while writers concurrently create newer row versions, without the reader ever needing to block on a writer's lock. A DNS zone transfer is an unrelated concept about replicating name server records. This multiple-versions-per-row approach is exactly why MVCC lets reads and writes proceed concurrently without blocking each other.
2 / 5
During a design review, the team relies on MVCC for a reporting query that must scan millions of rows over several minutes, specifically so the query sees a consistent snapshot without blocking concurrent writers or being blocked by them. Which capability does this provide?
MVCC here provides non-blocking, consistent snapshot reads concurrent with ongoing writes, since the reporting query reads row versions from its own snapshot rather than contending with writers for locks. Taking a read lock on every row for the query's entire multi-minute duration would block every concurrent writer from touching those rows for minutes at a time. This snapshot-without-locking behavior is exactly why MVCC is favored for long-running analytical queries running alongside live write traffic.
3 / 5
In a code review, a dev notices a long-running reporting query acquires a shared read lock on every row it scans and holds those locks for its multi-minute duration, blocking concurrent writers, instead of reading from an MVCC snapshot that requires no such locks. What does this represent?
This is a missed MVCC opportunity, since reading from a snapshot would let the query proceed without blocking concurrent writers for its entire multi-minute duration. A cache eviction policy is an unrelated concept about discarded cache entries. This lock-and-hold-for-minutes pattern is exactly the kind of contention a reviewer flags once concurrent reads and writes must coexist.
4 / 5
An incident report shows write throughput collapsed for several minutes because a long-running reporting query held shared read locks on millions of rows, blocking every concurrent writer that touched those rows during the query's execution. What practice would prevent this?
Running the reporting query under MVCC snapshot isolation lets it read a consistent view of the data without acquiring row locks that block concurrent writers. Continuing to acquire and hold shared read locks on every scanned row for the query's full duration regardless of how many writers it blocks is exactly what caused the throughput collapse described in this incident. This lock-free-snapshot-read approach is the standard fix once read-lock contention is confirmed to be blocking writers.
5 / 5
During a PR review, a teammate asks why the team relies on MVCC instead of simple shared and exclusive row locks for concurrency control, given that locks are conceptually simpler to reason about. What is the reasoning?
MVCC trades the storage and cleanup overhead of keeping multiple row versions for readers and writers that never block each other, while shared and exclusive locks are simpler but force readers and writers to contend for the same lock on a row. This is exactly why MVCC is favored in databases that must support concurrent long-running reads alongside writes, while simple locking remains acceptable when read and write concurrency stays low.