Why this matters: the booking system's core — show-owned seats, holds, idempotent confirm — is compact enough that interviewers always extend it. Each variation below lands against a seam from lesson 02, and as ever, the grading question is which seam absorbs the change and what provably stays untouched.

Pricing tiers: a table, not a seat map mutation

"Premium rows cost more" is the gentlest extension, and the design test is where the prices land. The tempting-but-wrong home is the seat map — a price on every seat-status entry — which entangles the system's hottest mutable state with static reference data. The clean home: a pricing table on the layout side — row (or zone) to tier, tier to price — sitting next to the screen's immutable layout, consulted at charge time. Availability stays a pure status record; pricing changes (weekend rates, matinee discounts) become table edits that never touch a lock-protected structure. This is the same layout-versus-availability split from lesson 02, extended: anything static rides with the layout; only status lives in the hot map. Say that rule and the interviewer knows the seam was principled rather than lucky.

Cancellation: the lifecycle grows, the mechanism doesn't

v1 froze BOOKED as terminal. Cancellation with a refund window ("free until 2 hours before the show") turns the booking itself into a small state machine — CONFIRMED → CANCELLED, with the window as a guard on the transition, and the refund amount a function of when the transition fires. The satisfying part is what already exists: cancelling means the show's seat map moves those seats BOOKED → AVAILABLE, and that's the same single-writer path every other transition uses — one new method on the show, inside the same lock. No new machinery; the seat lifecycle from lesson 02 just gains one arrow. Worth also naming the policy/mechanism split: the window is policy (product will tune it), the transition is mechanism — keep the window a passed-in rule so policy changes don't edit the show.

Group bookings: adjacency is a search problem on the layout

"Find four seats together" sounds like a booking feature but is actually a query before the claim: search the current availability for runs of adjacent seats, then feed the chosen run through the existing placeHold — whose all-or-nothing semantics were built for exactly this. Adjacency knowledge (which seats neighbor which, where the aisles break a row) belongs to the layout, so the search naturally lives beside it, reading availability but never writing. The race note worth volunteering: the search result is a suggestion, instantly stale — another group may claim those seats between search and hold. That's fine, and the design already answers it: the hold attempt fails atomically, and the user searches again. No reservation happens during search; truth still changes hands only in placeHold.

When the seat map leaves the process: a sketch

Everything so far assumed one process, where synchronized makes check-then-claim indivisible. The senior closing move is sketching — sketching, not building — what breaks with two booking servers. The answer echoes the rate-limiter chapter's framing: decide where truth lives, and put the atomic operation next to it. Two servers each holding a copy of the seat map means two writers and a race no lock can fix, because the collision now happens between machines. The fixes all follow one shape: a single authority for each show's seat state — a shared store where check-then-claim executes as one atomic operation, or a single owner process per show that serializes its claims. Holds get simpler in one way (TTLs become expirations the store enforces) and harder in another (clock skew between servers becomes real). In the round, name the shape and stop: "the show's seat map needs one home, and the claim must be atomic at that home — everything else in this design survives." Going deeper than that sketch is a distributed-systems interview, and volunteering the boundary is itself the point.