Design Inventory for a Flash Sale

Every claim takes a unit with a single atomic conditional operation on the authoritative stock (compare-and-decrement, a conditional update, or popping a pre-created unit token), so two concurrent claims can never both take the last unit; the per-shopper count is checked in the same atomic step.

The design works out that a top deal sees tens of thousands of claims a second on one item (66 million visitors, 5% in 60 seconds is about 55,000 per second) and splits its units across several shards or sub-pools that are claimed independently, while their total still equals the allocation.

A hold records its expiry; expiry is driven by a delayed queue or TTL and returns the unit to the pool exactly once, and a payment that arrives after expiry is rejected or must claim again.

Page loads read a cached or pushed count refreshed about once a second (hundreds of thousands of reads a second before a popular opening), never the authoritative stock.

Each deal's stock (or each shard of it) is owned by exactly one region at a time under a lease with fencing, so a region that comes back cannot keep selling units another region has taken over.

Every functional requirement in the brief is visibly served by something on the board, and the non-functional targets are addressed rather than ignored.

Components are labelled, data flows are drawn as connections between them, and the direction of each flow is unambiguous.