What concurrency schemes forbid

What this article forbids

Serializability without either waiting or aborting. There is no third currency, except commutativity, which changes the problem instead of solving it.
Exact, cheap conflict detection. Every practical scheme is conservative and pays in false conflicts.
A long-running transaction concurrent with a high write rate on overlapping data. That is arithmetic, not tuning.
Avoiding a collector once you have multiversioned.
Isolation behaviour that is independent of physical design. Because predicate locking is intractable, which index exists determines which locks are taken, which determines which transactions conflict.

Escapes and their prices

Escape	Price
Weaken the guarantee	The application pays, in anomalies
Multiversion	Space, a collector, and the oldest reader's veto over both
Partition and serialize	Cross-partition transactions become a cliff, not a slope
Determinize	No interactive transactions, advance access sets, a global sequencer
Commute	Works only where the operation has an algebra
Shrink W	The most underrated of the six, and the only one with no structural cost

Case, resolvedConstructed case · Tomas at Kestrel Tickets

A 3-hour report, and a table that tripled

A three-hour report grew the orders table from 40 GB to 130 GB, two support agents both left shift at 06:00 leaving nobody on, and switching a hot seats_remaining counter from locking to retry-on-conflict drove CPU to 100% while completed orders fell. Where it started: Multiversion and optimistic schemes →

The bloated table and the failing report. Lena explains that the three-hour report holds a snapshot open for three hours. In Postgres-style storage, vacuum cannot remove any version newer than that snapshot, so the table grows from 40 GB to 130 GB: the writers pay. In the undo-segment style used on the replica, the old versions are overwritten and the reader fails. The fix: move the report to a replica configured for long reads, set a limit on idle-in-transaction and long-statement time, and watch bloat growth as a metric before it hurts.

The two agents who both left. The check "at least two agents are on shift" reads data that the other transaction changes, and each transaction writes a different row. Snapshot isolation allows this (write skew). Tomas enables serializable isolation (SSI) for the rota transaction only. Now one of the two transactions gets a serialization failure and is retried; on retry it sees one agent already gone and refuses. The cost is a small, measured abort rate on a low-traffic table, not "a slowdown".

The hot counter. Lena estimates the conflict probability: 90% of 8,000 orders per second touch one row, so effective N is about 1 for those writes. Locking would queue them all; retrying would burn the CPU. The answer is not a different scheme. It is reformulating the operation: seats_remaining becomes 50 sub-counters, each with its own share of stock (an escrow), plus a rare background rebalance. Tomas also moves the call to the fraud-scoring service out of the transaction, cutting W from 20 ms to 5 ms.

Re-running the load test at 8,000 orders per second, the retry rate drops to under 1%, and p99 latency to 90 ms.