400
shoppers for every phone
Assume 5 million on the page and 4 million tapping Buy in two seconds, 2 million claims a second for 10,000 phones. 99.75% must lose.
Why one database row sells only 500 a second
“Subtract one if any are left” never oversells, but locks the row through a 2 ms commit. 10,000 phones take 20 seconds while 40 million requests arrive.
Move the counter to Redis. One key, or eight?
Bad: One key
One script, one thread: about 40,000 claims a second.
Good: Eight buckets of 1,250
≈ 320,000 a second. Routed by user, so one script checks one-per-customer.
4 million taps in two seconds, 10,000 phones. A race rewards bots and fast networks.
The trick
Draw lots at the edge. Each pass gets one fixed random number; about 11,000 of the lowest get in.
5 million on the page. 11,000 reach the stock.
Each layer answers most of what reaches it. Every “no” comes from the edge in milliseconds; the counter sees about as many attempts as units.
Redis says yes; the database decides
- A script on your bucket says yes
- Wait for a replica and Kafka
- Only then tell you “pay by 12:10”
- Orders at 1,000/s; the database caps each bucket
If 15% don’t pay, 1,500 phones return at 12:10
Deadlines collide, so they return within two seconds, a second flash sale. Send them to the waitlist; only scripts still hammer the open counter.
Remember
Say no at the edge, yes in one script on one bucket, and make the yes real behind a queue, with the database as referee.