AI InterviewSearch…Search problems, topics, or pages…Ctrl KGet started
Skip to content

06 Movie ticket booking / Checkpoint

Checkpoint: Movie ticket booking

25 min · +25 XP · 1 exercise · 10 questions

Exercise0/1
Quiz · 70% to clear10 q

This checkpoint covers the module: ShowSeat and its states, all-or-none holds that expire, payments that confirm or release, pricing as a Strategy, and how two buyers racing for one seat are kept apart.

How it works. Ten questions and one program. You need 70% on the questions and the program accepted to clear the module. Retake it as often as you like; your best score counts.

Before you start, make sure you can answer these from memory:

  • Which object holds a seat's status, and why not Seat?
  • What makes a lapsed hold read as available without a timer?
  • What happens to held seats when a payment fails, and when it succeeds after the hold lapsed?
  • How does a version number let exactly one of two buyers win?
  • Where does a pricing rule live, so a new one changes no booking code?

The program is the race itself: buyers read a seat's version and then try to write, and a write with a stale version loses. Trace the example by hand first; the case most people miss is a buyer whose own earlier write made their read stale.

Common questions

How do you stop two users booking the same seat?

Let one conditional write decide. With optimistic locking each seat carries a version, and a hold succeeds only if the version is still the one the buyer read; with pessimistic locking the seat row is locked with SELECT ... FOR UPDATE first. A unique constraint on (show, seat) is a backstop.

What is optimistic locking in a booking system?

Reading a seat also reads its version number. The write that holds it says "only if the version is still N" and raises it to N + 1; a second buyer who read N too finds the version moved and changes nothing, so exactly one of them wins.

Why is an in-memory lock not enough for seat booking?

A real booking service runs on several servers, and a synchronized block or Java lock only guards one process. The decision has to be made where every server sees it: in the database, with a conditional update or a row lock.

AI InterviewGet started

BookMyShow LLD Quiz: Seat Holds, Locks and Pricing Practice

Practise the movie ticket booking machine-coding problem: ten questions on seat state, holds, payments and locking, and a Java program with optimistic versions.

  • Course: Low-Level Design study plan
  • Module: Movie ticket booking
  • Kind: Checkpoint — cleared at 70%
  • Reading time: 25 min
  • Runtime: OpenJDK 18

Checkpoint: Movie ticket booking is the checkpoint that closes the Movie ticket booking module: a graded quiz and whole-program exercises, passed at 70%.

Instructions

This checkpoint covers the module: ShowSeat and its states, all-or-none holds that expire, payments that confirm or release, pricing as a Strategy, and how two buyers racing for one seat are kept apart.

How it works. Ten questions and one program. You need 70% on the questions and the program accepted to clear the module. Retake it as often as you like; your best score counts.

Before you start, make sure you can answer these from memory:

  • Which object holds a seat's status, and why not Seat?
  • What makes a lapsed hold read as available without a timer?
  • What happens to held seats when a payment fails, and when it succeeds after the hold lapsed?
  • How does a version number let exactly one of two buyers win?
  • Where does a pricing rule live, so a new one changes no booking code?

The program is the race itself: buyers read a seat's version and then try to write, and a write with a stale version loses. Trace the example by hand first; the case most people miss is a buyer whose own earlier write made their read stale.

Common questions

How do you stop two users booking the same seat?

Let one conditional write decide. With optimistic locking each seat carries a version, and a hold succeeds only if the version is still the one the buyer read; with pessimistic locking the seat row is locked with SELECT ... FOR UPDATE first. A unique constraint on (show, seat) is a backstop.

What is optimistic locking in a booking system?

Reading a seat also reads its version number. The write that holds it says "only if the version is still N" and raises it to N + 1; a second buyer who read N too finds the version moved and changes nothing, so exactly one of them wins.

Why is an in-memory lock not enough for seat booking?

A real booking service runs on several servers, and a synchronized block or Java lock only guards one process. The decision has to be made where every server sees it: in the database, with a conditional update or a row lock.

Exercise

Two buyers, one seat

Decide races for seats with optimistic locking: every seat has a version, every change of status raises it by one, and a hold is a conditional write that succeeds only if the version is still the one the buyer read.

Input. The first line lists the seat ids. Then one command per line:

  • READ user S: the buyer reads the seat; remember the version they saw (a later read replaces it). Print user reads S: STATUS vN.
  • HOLD user S: if the user never read S, print user must read S first. If the seat's version differs from the one they read, print user lost S: version is N, read M. If the versions match but the seat is not AVAILABLE, print user cannot hold S: STATUS. Otherwise it becomes HELD by the user: user holds S vN with the new version.
  • BOOK user S: if the user holds it, it becomes BOOKED: user booked S vN.
  • RELEASE user S: if the user holds it, it becomes AVAILABLE: user released S vN. For both, a seat the user does not hold prints user does not hold S.
  • SHOW: every seat in the order listed: A1 AVAILABLE v0, A2 BOOKED v4.

A seat id that is not listed prints no such seat S for any command.

Example

A1 A2
READ alice A2
READ bob A2
HOLD alice A2
HOLD bob A2

prints

alice reads A2: AVAILABLE v0
bob reads A2: AVAILABLE v0
alice holds A2 v1
bob lost A2: version is 1, read 0

In this module: Movie ticket booking

← Movie ticket booking: holds, payments and the race · Expense sharing: splits, balances and settling up →