Millions of customers attempt to buy a small number of items at a scheduled instant. Which performance constraint dominates, and why do conventional scaling techniques fail against it?

The dominating constraint

Write contention on a single row. Every buyer is competing to decrement the same inventory counter, which serialises through one lock on one record on one node.

That is a fundamentally different problem from throughput. Horizontal scaling adds capacity for independent work; here all the work is dependent on one item of state, so adding nodes adds queueing in front of the same bottleneck. The system's ceiling is the rate at which one row can be updated — typically a few thousand operations per second — against millions of concurrent attempts.

Why conventional techniques fail

Caching. Reads can be cached; the decrement cannot. And a cached availability read used to make the reservation decision is how overselling happens — it works under normal load and fails during exactly the surge that made caching seem necessary.

Read replicas. Irrelevant. This is a write problem.

Autoscaling. The event arrives in seconds; provisioning takes minutes. And more application instances means more concurrent attempts at the same row, which makes contention worse rather than better.

Sharding. The item is one logical entity. Sharding by item does not help when one item receives all the traffic.

What actually works

1. Admission control before the contention point. Only admit as many requests as could plausibly succeed. If 500 units are available, admitting 5,000 requests and rejecting 4,500 after they have consumed database resources is waste; rejecting them at the edge costs microseconds. This is the single most important control.

2. Split the counter. Divide 500 units into segments held separately, each with its own row. Buyers are routed to a segment, so contention divides by the segment count. The cost is complexity in handling a segment that empties while others have stock, and it works because approximate fairness is acceptable.

3. Move the decrement to an in-memory store with single-threaded atomic operations, and persist the outcome asynchronously. Removes disk and transaction overhead from the contention point. Requires careful durability design, since the authoritative count now lives somewhere less durable.

4. Queue the purchase intent, then process serially. Converts contention into an ordered queue, which also gives fair first-come-first-served semantics and a controllable processing rate. The user sees "your request is being processed", which is honest.

5. Pre-declare the winners. For the most extreme events, allocate entitlements in advance — a lottery or a registration window — so the instant of the sale is a redemption rather than a race.

The architectural insight

The one invariant that cannot be compensated is inventory correctness. A double charge is refundable; a double sale of a limited item is not. So the design protects the reservation with strict consistency and sheds everything around it — recommendations, reviews, search facets, view tracking — rather than weakening it.

Identify the invariant that cannot be compensated, protect it properly, and refuse to pay for strong consistency anywhere else.