Lesson 12 of 15
43. Design Flash-Sale Ticket Booking (Ticketmaster / IRCTC Tatkal)

Score yourself

3 min read+10 XP

Score yourself

Give yourself 0, 1 or 2 points per row.

Area0 points1 point2 points
RequirementsStarted drawingBook a seatBurst, oversupply of buyers, no double-sell, fairness and bots agreed
EstimatesNoneNumbers, not used laterPeople per seat, admit rate and refresh storm drove the waiting room
API and dataSkippedBook endpoint onlyJoin/status/admission token, holds with expiry, seats by section
High-level designScale the booking APIQueue without detailsStatic countdown, waiting room, admission, holds, payment, sold-out walked
Deep diveHand-wavedOne topicWaiting room mechanics, seat holds, bot defences or fairness with numbers
Trade-offsNone namedNamed when askedRaised unprompted (FIFO vs randomised, hold length, admit rate vs speed)
CommunicationLong silencesMostly clearThought out loud, checked in, managed time

12 to 14: strong hire signal. 8 to 11: solid, polish the weak rows. Under 8: redo the round in a week, timer on.

The bar: fresher vs SDE-2

FresherSDE-2
LoadAutoscale serversWaiting room admitting at the rate seats can be sold; static pre-open page
SeatsLock a rowConditional holds by section, expiry, best-available assignment
BotsCAPTCHAVerified accounts, limits, edge detection, signed admission tokens
FairnessFirst-comeRandomised opening window, one spot per account, lotteries
HonestyErrors under loadAccurate position, ETA and instant "sold out"

Common mistakes

  • Letting everyone hit the booking API at 10:00 and hoping autoscaling copes.
  • Holding seats without expiry, or for too long.
  • First-come by milliseconds, which hands the sale to bots.
  • No admission token, so bots skip the queue by calling booking APIs directly.
  • Keeping people waiting after seats are gone.

Quick check

Five questions on this chapter. Pick an answer, then check it.

quiz