Why this matters: movie-ticket booking is the machine-coding canon's concurrency-flavored problem — not because you'll write threads, but because one scenario dominates the grading: two users, same seat, same moment. Candidates who model theatres, screens, and movies for twenty minutes before touching that scenario have built scenery. The requirements conversation exists to find the race early and put it at the center.

The prompt, as given

Design a movie ticket booking system.

A theatre runs shows of movies on its screens. Users browse a show's seat map, pick seats, pay, and get a booking. Two users must never end up with the same seat for the same show.

The last sentence is the entire problem. Everything before it is nouns; that sentence is the invariant — and the prompt says nothing about how it's kept when payment, the slowest step, sits in the middle of every booking.

The organizing question: two users race for F7

Open with the scenario, not the entity list: "Two users are both looking at seat F7 for the same show. Both tap it. Both proceed to pay. What does each one experience?" This single question forces every real decision in the problem:

"Is picking a seat a reservation?" Yes — a hold: picking F7 gives that user a temporary exclusive claim while they pay, and the second user is told immediately that F7 is taken. First-tap-wins, decided at the moment of the tap. The alternative — both proceed and the loser finds out after paying — is the experience the hold exists to prevent.

"How long does a hold last?" Five minutes. Payment is slow and users abandon carts; without an expiry, an abandoned hold makes F7 unsellable forever. The TTL is what makes holds safe to grant freely — worth asking, because the number determines a real mechanism (something must expire holds, which lesson 02 takes seriously).

"What is payment, to this system?" An external call that can succeed, fail, or — the honest case — time out with the outcome unknown. It happens after the hold, never before a claim exists. A failed payment releases the hold; the seat returns to the pool.

"Can a confirmation arrive twice?" Ask this and interviewers sit up. Payment providers retry their success callbacks; confirming a booking must be retry-safe — the second identical confirmation is absorbed, not double-booked. That's a requirement about state transitions, and it shapes the booking model directly.

"Seat map per what, exactly?" The quiet trap in the problem. Availability is per show, not per screen: the same physical seat F7 is free for the 6 pm show and taken for the 9 pm show, and it's a different F7 next week. Anchoring seat state to the screen is the classic modeling error here — the screen owns the layout; each show owns its own availability.

"Scope?" Pricing, discounts, and concessions: out. One process, in-memory state. The race, holds, and payment-edge handling are the whole game.

The requirement set this chapter builds against

The race      two users, one seat: first tap wins, decided at tap time
Holds         picking seats = temporary exclusive claim (TTL 5 min);
              expiry returns seats to the pool automatically
Payment       external call, AFTER the hold; can succeed, fail, or
              time out; failure releases the hold
Confirm       retry-safe: duplicate success callbacks must not
              double-book or error
Seat map      per SHOW (screen owns layout; each show owns its own
              availability) — same seat, different shows: independent
Scope         pricing/discounts/food: out; single process, in-memory

As with every chapter in this course: a live interviewer's answers may differ — a different TTL, or holds granted at checkout rather than tap. The conversation is the skill; this answer sheet is just the one we build against.