A flash sale puts 500 units of one product in front of 200,000 concurrent shoppers. Design the inventory path.

What the interviewer is testing

Whether you recognise this as a hot-key contention problem with a hard global invariant, and whether you can avoid overselling without serialising 200,000 requests.

Why the obvious approaches fail

A row lock on the inventory record. Every request contends on one row. Throughput is bounded by lock acquisition on a single item — perhaps hundreds per second — while 200,000 requests arrive in seconds. The database becomes the queue and everything times out.

Optimistic concurrency with retries. At this contention almost every attempt fails and retries, producing a retry storm that multiplies load without increasing throughput.

Eventual consistency. Oversells. There are 500 units and no way to un-sell the 4,000th order.

The design

Admission control before inventory. The decisive move is that 199,500 of these requests must never reach the inventory system. A token or queue system admits a bounded number of shoppers to the purchase path — the rest are told immediately that the item is unavailable, or held in a queue with a position.

This converts a contention problem into a capacity problem, and it is the difference between a system that works and one that melts.

Decrement a distributed counter, not a database row. An atomic counter in an in-memory store handles the admitted requests at high throughput. Reserve first, confirm the order afterwards.

Partition the stock. Split 500 units into buckets across shards — 50 units on each of 10 shards — so contention is divided. Requests route to a shard; a shard that is exhausted either fails fast or falls through to another. This trades a small amount of accuracy at the boundary for a large increase in throughput.

Reservations with expiry, so a shopper who abandons checkout releases their unit automatically.

What a strong answer adds

The queue is a product feature, not just a technical control. Telling a shopper "you are position 3,000" is a better experience than a spinner followed by failure, and it makes the admission control comprehensible rather than arbitrary.

And the pre-event work: this path must be load tested at the real concurrency with the real distribution, because a uniform load test at peak volume proves nothing about a workload where essentially all traffic targets one key.

Common weak answers

Scaling the database. Caching the inventory count, which produces stale reads and oversells.