Design a Flash Sale (BFCM Scale)

Shopify runs the checkout for millions of independent merchant stores on shared infrastructure, so its single hardest engineering event is a coordinated write spike. That event has a name here: BFCM, the Black Friday and Cyber Monday weekend that is the busiest shopping stretch of the year. A flash sale, sometimes called a product drop, is the sharp version of it. One limited item, a sneaker or a console, goes live at a set minute, and a wave of shoppers all press buy at the same instant on the same product. Demand arrives faster than stock exists, and it all points at one row of inventory. That row is the whole fight.

Say the shape of the problem out loud before drawing anything. It steers every later choice. This is not a throughput problem you cache your way out of. Reads are easy to cache, but a purchase is a write, and every one of these writes competes for the same scarce resource, the last few units of a single product. Two things can go wrong. One is overselling, promising more units than exist. The other is falling over, letting the surge take down checkout for this store and its neighbors. So the design is about controlling how fast requests are allowed to touch the hot inventory, and about turning most shoppers away cheaply and fairly when the stock runs out. That framing, admission control plus write contention, is the whole round.

The Shopify angle

Surviving Black Friday is Shopify's engineering identity, and this prompt is the purest expression of it. A recent BFCM peaked near 32 million requests a minute across the platform, on a weekend that moved billions in merchant sales. The interviewer wants to hear that the queue page is the design, not an afterthought. The weak opening reaches for a caching layer or a read replica. Those solve the read side, and the whole problem lives on the write side. Open instead with how you keep the rate of buy requests hitting one product's stock at a level the system can safely commit. That is the sentence that lands.