The ten o’clock rush (ticket booking under a flash sale)

Before you start. Three things are borrowed. Design the Whole Thing (the interview, assembled) gave you the six steps of a design answer: clarify, estimate, API, data, design, scale. Two people, one seat (thread-safe booking) gave you a seat that is held for a few minutes and a write that only succeeds if nobody changed the row first, all inside one program. Charged Twice (idempotency & exactly-once) gave you the retry that must not charge a customer twice. This lesson takes that single seat and puts a million people in front of it.

The idea in 30 seconds

A flash sale is a demand problem: far more people than seats, all inside one minute. The system’s job is to finish bookings fairly, not to let everyone in.
A virtual waiting room puts a queue of tokens at the edge and admits people at the rate the booking core can take. Position over admit rate is the honest wait.
Inventory is counted in one place per train or show, and a sale is a conditional decrement, never a read then a write. Overselling is the failure that cannot happen.
A reservation hold takes a seat off the market for a few minutes with a deadline, and expired holds feed seats back to the chart.
Payment carries an idempotency key, so a retried request returns the first answer instead of charging again.
The seat map is a stale cache, and only the book button hits the strict write path.

Read the story

In this lesson

10:00 in India: the hour a train’s last seats go

The doorkeeper: a virtual waiting room

One chart on the wall: inventory, counted in one place

Holding a seat while someone fumbles with a card: a reservation hold

The cashier’s slip: payment and an idempotency key

Two paths with two standards

Terms it explains: virtual waiting room, inventory, stale, row, one place per train, overselling, reservation hold, idempotency key, cache, read path, write path.

Index

Open everything on chalk.

The ten o’clock rush (ticket booking under a flash sale)

In this lesson