Section 1: Sixty Thousand Seats, Three Million Fans - Problem Understanding & Clarifications

Executive Summary: The prompt reads like a shopping cart: list events, show a seat map, take a payment, send a ticket. Underneath sit two problems the cart hides. The first is contention: many fans reaching for the same seat in the same second, when each seat is unique and may be sold at most once. The second is a flash crowd: three million fans for 60,000 seats, two million of them in the first minute. We decompose the prompt, ask six clarifying questions that each move the design, draw the line against three sibling modules, and meet Jordan, whose two-seat purchase we follow throughout.

The interviewer reads from a card:

"Design a ticket booking service like Ticketmaster. Fans browse events, pick specific seats on a seat map, hold them for a few minutes while they pay, and get tickets. The hardest case: a stadium show with 60,000 seats goes on sale at 10:00 and three million fans show up."

Most first answers look the same: an events table, a seats table with a status column, an endpoint that flips a seat to sold, a payment call. It works for a local theatre. It fails at 10:00:01 on Friday, in two ways.

Two fans tap Section 112, Row F, seat 8 in the same millisecond. If the code reads the status and then writes it, both see "available" and both write "sold". That is the contention problem, a correctness bug: one seat, two tickets. Meanwhile three million browsers refresh the event page. That is the flash-crowd problem, an availability bug: the database that must get seat 8 right is being buried by page loads.

Key Insight: A ticket booking system is a CRUD app wrapped around two hard problems. The Staff answer names both in the first ten minutes and keeps them apart: the hold decides who gets a seat, and the waiting room decides who gets to ask.

Decomposing the Prompt

Before asking anything, map the territory out loud:

• What it does: Sells numbered seats for one show, each at most once. Row F seat 8 is not interchangeable with seat 9, so the seat map is the product. The verbs: browse, queue, pick, hold, pay, issue.
• Who uses it: Fans (nearly all the traffic), organisers who set up venues and prices, and gate staff checking tickets. Also adversaries: bots joining the queue thousands of times, scalpers buying the limit to resell, people selling one barcode screenshot twice. They have the strongest incentive of anyone here, so they are in the design from the start.
• Why it's asked: It looks like CRUD, so it tests whether you find both hidden problems unprompted.
• How it's used: Calmly on a normal day, at about 6 orders a second. Against a stopwatch on sale day, with the year's hardest load packed into minutes.

Quick check before moving on: