Flash sales and ticket drops: handling 10× traffic gracefully
A flash sale is a traffic spike with a stopwatch on it — and a second problem most scaling advice ignores entirely: there is only so much stock, and everyone wants it at the same instant.
A flash sale looks like a smaller Black Friday, and preparing for it as though it were one is how drops go wrong.
Black Friday is a capacity problem: more people than usual, spread over hours, buying from a broad catalogue. A drop is a contention problem. Ten thousand people want the same 200 items in the same sixty seconds. The traffic is the easy half. The hard half is that your inventory is a small number that many concurrent processes are all trying to decrement, and every second of the sale is a race.
So this is organised around the three problems in the order they will hurt you.
Problem 1: everyone arrives at once
The good news is that this is the part you already know how to solve, and much of the arriving traffic is asking for identical things. The landing page, the countdown, the product images, the CSS — all the same for everyone, all cacheable, all servable from the edge without your origin noticing.
Two specifics matter for drops in particular. Warm the cache before the announcement, because a cold cache at the moment of a coordinated arrival means thousands of simultaneous misses all stampeding your origin for the same page. And make sure your CDN collapses concurrent misses for the same object into a single origin request, rather than forwarding all of them — this behaviour goes by several names, but its absence is exactly the failure that takes an origin down at T-zero.
The refresh behaviour is worth planning for too. In the minute before a drop, a large fraction of your visitors are pressing F5 repeatedly. A countdown page that is fully cached absorbs this. A countdown page that queries the database for the current server time does not.
Problem 2: stock is a number and everyone wants it
This is the part that separates drops from every other traffic event, and it is not a caching problem at all.
When 5,000 people click "buy" on 200 units within the same second, your system has to decide who gets them. Do that carelessly and you oversell — you take 400 orders for 200 items and spend the following week cancelling half of them, refunding, and apologising. Do it too cautiously and you serialise the whole sale behind a single lock, and everyone waits.
- Decrement stock atomically at the database. A conditional update that only succeeds when stock remains is safe. Read-then-write in application code is not, no matter how fast it looks.
- Reserve at add-to-cart, not at payment. With a short expiry. Otherwise you sell the same unit to everyone who reaches checkout, and the losers find out at the payment step, which is the worst possible moment.
- Do not show live stock counts on a cached page. Either omit them or load them separately. A cached "3 left" that is actually zero generates more support email than no number at all.
- Decide your oversell policy in advance. Some businesses accept a small oversell and honour it; some never do. Either is defensible. Discovering you have no policy at 20:01 is not.
- Cap quantity per order and per account. Simple, and it does more against resellers than most bot detection.
Problem 3: a meaningful share of the crowd is not human
Limited-stock drops attract automated buyers, and they are good at this. A script can complete checkout in a fraction of the time a person needs to type a card number, and the people running them do it professionally.
If you do nothing, the honest description of a drop that sells out in eleven seconds is not that demand was extraordinary. It is that bots bought your stock to resell it, your actual customers got nothing, and the goodwill you were building went to a secondary market instead.
What works, in order of effectiveness for the effort:
| Measure | Effect | Cost to real customers |
|---|---|---|
| Quantity caps per account and payment method | High | None |
| Proof-of-work challenge on add-to-cart and checkout | High | Milliseconds |
| Rate limits on the purchase endpoints | High | None if set sensibly |
| Require an account created before the drop | Very high | Excludes new customers |
| Randomised queue position rather than strict arrival order | Moderate | Feels less fair to early arrivals |
| CAPTCHA at checkout | Low — solving services are cheap | High friction |
Watch for the drop being bought before it opens. Bots routinely find product URLs and API endpoints before the announced time by guessing URL patterns or watching your sitemap. If the product page exists at 19:55 and the add-to-cart endpoint works, the sale started at 19:55 whatever your countdown says.
Putting the three together
The architecture that holds is layered, and each layer protects the one behind it:
Edge cache absorbs the arrival
Landing page, countdown, images and assets served entirely from the edge, warmed in advance, with concurrent misses collapsed.
A waiting room meters the flow
Admit buyers at the rate your checkout can genuinely sustain, rather than letting all of them collide with it simultaneously.
Challenges and limits filter the purchase path
Add-to-cart and checkout carry rate limits and a proof-of-work challenge, so automated volume becomes uneconomic.
The database arbitrates stock atomically
Conditional decrements, short-lived reservations, and a quantity cap. This is the last line and it must be correct.
Notice that only the last layer has to be exactly right. The first three exist to reduce how much load and how much adversarial traffic reaches it — which is the general principle behind all of this, and the reason drops are survivable at all.
Afterwards
Write it down while it is fresh: how long the stock lasted, how many orders were cancelled, what the queue looked like, what broke, what you were surprised by. Drops recur, often with the same customers and the same bots, and the second one is enormously calmer if someone wrote a page of notes after the first.
Frequently asked questions
How do I stop my website crashing during a flash sale?
Cache everything that is identical for all visitors — landing page, countdown, images and assets — and warm that cache before you announce, so the coordinated arrival does not produce thousands of simultaneous cache misses. Put a waiting room in front so buyers reach checkout at a rate it can sustain, and rate-limit the purchase endpoints. The uncacheable checkout path is what fails, so the goal is to control how much traffic reaches it.
How do I prevent overselling during a limited-stock drop?
Decrement stock atomically in the database using a conditional update that only succeeds while units remain, rather than reading stock and then writing in application code, which races under concurrency. Reserve stock at add-to-cart with a short expiry rather than at payment, so shoppers do not discover at the payment step that their item is gone. Cap quantity per order and per account, and decide your oversell policy before the sale rather than during it.
How do I stop bots buying all my limited stock?
Quantity caps per account and payment method are the most effective measure for the least friction. Add rate limits and a proof-of-work challenge on add-to-cart and checkout, which cost a real browser milliseconds and make automated volume uneconomic. CAPTCHAs are largely ineffective here, since solving services are cheap and resellers use them routinely. Also confirm the product URL and purchase endpoint are not reachable before the announced start time.
Should I show live stock levels during a drop?
Not on a cached page. A cached page showing "3 remaining" when the true figure is zero produces more customer frustration than showing no number at all. Either omit stock counts from cached pages, or load them through a separate uncached request that can be rate-limited independently, accepting the extra origin load that creates.
What is the difference between preparing for Black Friday and a flash sale?
Black Friday is primarily a capacity problem — more visitors than usual, spread over hours, buying across a broad catalogue. A drop is a contention problem: many people competing for a small, fixed quantity in seconds. That adds concerns Black Friday does not have, notably atomic stock handling to prevent overselling and defences against resale bots, on top of the traffic handling both events require.
Design for concentration and contention, not just volume, and a drop becomes a demanding sixty seconds rather than a bad evening.
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
