Design Hotel Booking

Design Hotel Booking

Step 1 of 10

stay3 nights

A stay is not a night, it is a range of them — and every one has to be secured together.

The Idea

Sell a room for a date range exactly once. Two guests pressing book in the same second must not both win, and a stay only exists if every one of its nights was secured together.

Real-World Example

A wall planner with a row per room and a column per night. A four-night stay is four squares shaded at once, and a pen that can only reach three of them has not booked anything.

BEGIN
  UPDATE availability SET booked = booked + 1
  WHERE room_type = ? AND night IN (n1..n4) AND booked < total
  -- rows updated must equal nights requested, else ROLLBACK
  INSERT booking(...)   -- unique (room, night)
COMMIT

The Tradeoff

One transaction across the range makes a partial booking impossible and holds locks that the next booking wants, so contention grows with the length of the stay. Under that, a unique constraint on room and night refuses a duplicate even when the logic above it is wrong.

Your turn

Put the steps in the right order.

1. 1Commit, so the guest holds every night or none of them↑↓
2. 2Open a transaction over every night in the requested range↑↓
3. 3Insert the booking row, which the unique constraint guards↑↓
4. 4Roll back unless each night still has a room free↑↓

Check order

Mini quiz

1 / 3

Every night of a stay is written in one transaction because:

• AIt is faster that way
• BThree nights out of four booked is not a booking
• CDates have to be sorted
• DIt avoids building an index