Art of Codeartofcode
Lesson 10 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.9 How do you keep it fair?

3 min read+10 XP

First-come, first-served by milliseconds rewards speed: bots, people on fast connections, people near the data centre. Fairer designs:

first-come by milliseconds gives bots all 1,000 seats; a per-account limit gives them 500; one queue spot per account with a randomised opening window gives them 53.

Figure: in the opening burst, don't race; draw lots.

  • Randomise the opening window: everyone who joins in the first, say, 30 seconds after opening (or before it, in a pre-queue) is treated as arriving at the same time, and their order is randomised. After that window, it's first-come.
  • One spot per account, however many requests it sends.

In the chapter's code, combining both drops bots from 1,000 seats to about 53: roughly their share of accounts (500 of 10,500, about 5%). Better bot detection (43.8) shrinks that share further.

Other fairness choices to discuss:

  • Lotteries for extremely oversubscribed events (register in advance; winners get a time slot to buy).
  • Purchase limits per account and per payment card.
  • Transparency: publish the rules (randomised window, limits) so people trust the outcome.

Memory code: "In the first rush, everyone is equal: shuffle, then serve."