500 Tatkal seats, 2 million people: it's not a database problem

transcript

10 AM sharp. Two million people tap Book. There are 500 seats. Ten seconds later, every seat is gone. How do you say no that fast?

That's 4,000 requests for every seat. So 99 point 975 percent must fail. Fast, and fairly. And they arrive at once. About 280,000 a second in the opening burst.

Most people say: just subtract one from the seat count. At 280,000 a second? Everyone queues on one row lock. Even the winners time out. Shard it? Ten shards of 50 seats. That's just ten hot rows instead of one.

Here's the twist. This isn't a database problem at all. It's admission control, wearing a database's clothes.

Put something dumb in front. One atomic counter per seat pool, in Redis. Counter at zero? Sold out, in milliseconds. Nothing written to disk. About 500 get a ticket to try. Only they move on. A single writer assigns real berths. An ordinary transaction.

But here's the catch. Read the count, then decrement it? Thousands read one seat left, and all get through. So the check and the decrement run in one Lua script. Atomically.

The database sees about 500 requests. Not 2 million. Losers store zero bytes. More database servers don't add seats. They only change how fast you say no.

Full breakdown in the lecture.