Art of Codeartofcode
Lesson 9 of 15

43. Design Flash-Sale Ticket Booking (Ticketmaster / IRCTC Tatkal)

1
The interview prompt
2
43.1 What do you ask first?
3
43.2 How big is this, really?
4
43.3 What are the doors?
5
43.4 What do we store?
6
43.5 What does the whole system look like?
7
43.6 How does the waiting room work?
8
43.7 How does seat locking work?
9
43.8 How do you rate-limit bots?
10
43.9 How do you keep it fair?
11
43.10 What would you say in the last five minutes?
12
Score yourself
13
Variations to practise
14
Sources
15
Code lab
43. Design Flash-Sale Ticket Booking (Ticketmaster / IRCTC Tatkal)

43.8 How do you rate-limit bots?

3 min read+10 XP

Bots buy tickets to resell at a markup, and they're fast and numerous. Layered defences (Chapter 25):

  • One queue spot and a ticket limit per account, with accounts that are costly to fake: verified phone or ID, payment card checks, account age. (Ticketmaster's "Verified Fan" pre-registration is one example of tying a sale to verified people.)
  • Edge bot detection (Chapter 25): per-IP and per-device rate limits, browser checks, CAPTCHAs at join time, blocking known data-centre IP ranges.
  • Signed admission tokens: booking APIs can't be called directly without passing through the queue.
  • Post-sale checks: cancel tickets bought by accounts that turn out to be linked, and make resale harder (named tickets, tickets in the app only).

In the chapter's code, with 1,000 seats, 10,000 people and 500 bots each firing 10 requests at 10:00:00.001, plain first-come gives bots every seat. A one-ticket-per-account limit alone still gives them 500, because they're always first in line. That's why fairness (43.9) matters as much as limits.

Memory code: "Make accounts expensive to fake, and make the queue the only door."