What Keeps the Site Up During a Flash Sale?

maang.io System Design Series

What is this?

It is 10:00:00 sharp. A limited run of 5,000 sneakers — or concert tickets, or a new phone — goes on sale. The countdown hits zero, and in the same handful of seconds, 1,000,000 people mash the "Buy" button. Refresh, refresh, refresh. Most sites would simply fall over: the database melts, the page times out, half the orders go through twice, and the other half oversell stock that doesn't exist.

A well-built one stays up. Not because it has one magic trick, but because it survives the way a city survives a flood — with layers. A levee here, a spillway there, a pump downstream. No single wall holds back the whole spike; instead each layer absorbs, spreads, or sheds a slice of the load, so that what finally reaches the fragile core — the part that decrements real stock — is a trickle it can handle correctly.

This is the grand finale of the 101 tier. The URL capstone showed every building block cooperating in sequence to serve one calm request. This one shows every building block cooperating under stress — DNS, the CDN, the load balancer, rate limiting, the API gateway, caching, message queues, the ACID transaction, and CAP, all leaning into the same storm at once. We'll walk it outside-in, from the edge of the internet down to the one row in the database that must be exactly right.

The one-line idea: a traffic spike isn't survived by one trick — it's survived by a layered defense where each 101 building block absorbs, spreads, or sheds a piece of the load, so a flood of 1,000,000 requests arrives at the database as a sustainable trickle of correct writes.

The order matters again, but in a new way. In the URL story the order was forced by protocol dependencies. Here the order is a deliberate defense in depth: you want each request stopped as far from your database as possible, because every layer it survives is more expensive than the last. A request answered by the CDN costs you almost nothing; a request that reaches the database costs you a lock, a disk write, and a slice of your finite throughput. Let's watch the funnel.