jdfive

Clarify Requirements

The interviewer just said…

“Design a movie ticket booking system.”

You nodded. Now you talk — for two or three minutes, with questions, not answers.

What you should do next

Ask clarifying questions in four buckets. Write the interviewer’s answers on the board (or pretend they said “reasonable defaults” — use the agreed list below).

1. Capabilities — what can users do?

  • Search movies playing in a city (not global search unless they say so)
  • List shows for a movie (time, theater, screen)
  • View available seats for a show
  • Book seats and receive a ticket
  • Cancel a ticket and get seats back (refund stubbed)

2. Rules — how does booking behave?

  • A seat can be booked by one user at a time
  • Between “I want these seats” and “payment succeeded,” seats should be held (reserved), not double-sold
  • If payment fails, held seats return to available
  • Cancel releases seats for others

3. Errors — what failures matter?

  • Seat already taken → tell user, pick different seats
  • Payment fails → release hold
  • Payment succeeds but booking fails → release + refund (compensation)
  • Ticket generation fails after booking → user still has a booking; reconcile async

4. Scope — what are we NOT building today?

Confirm explicitly. Weak candidates assume everything; strong candidates negotiate v1.

Agreed requirements (v1)

Use this as your working contract unless the interviewer overrides:

# Requirement
R1 Search movies by city
R2 List shows for a movie (theater, screen, date/time)
R3 Show available seats for a given show
R4 Book seats: hold → pay → confirm → ticket
R5 Cancel ticket; seats become available again

Data you need: Movie, Theater (with city), Screen (seat layout), Show (movie + screen + slot), per-show seat inventory (ShowSeat), Ticket.

Seat lifecycle: AVAILABLE → RESERVE (soft hold) → BOOKED (confirmed after payment).

Explicitly out of scope for v1

Say these out loud so the interviewer can push back if they disagree:

Out of scope Why defer
UI / seat map rendering LLD focuses on services and state, not front-end
Real payment gateway (Stripe, Razorpay) Stub PaymentService; return a fake paymentId
Multi-city inventory sync across regions Single deployment, in-memory or single DB is fine
Pricing tiers, coupons, loyalty points Adds rules without testing core booking
Waitlists, partial seat blocks (couples only) Nice extensions; not v1
Email/SMS notifications Mention as async follow-up, don’t implement

Translate requirements to nouns (preview)

You don’t need full diagrams yet — just name what you’ll draw next:

Movie ──< Show >── Screen ── Theater (city)
                    │
                    └── ShowSeat (showId, seatId, status, reserveTime)
Ticket (userId, showId, seats, paymentId)

Services implied by requirements:

  • MovieService — search by city
  • ShowService — shows, availability, reserve/book/release
  • BookingService — orchestrates the saga
  • TicketService — create/find ticket
  • PaymentService — stub