Design a Hotel Room Reservation System

The prompt starts small on purpose: "Design the reservation system for one hotel — a 220-room beachfront property in Miami. A guest picks dates, picks a room type, pays, gets a confirmation number. Then tell me what has to change when we roll it out across Marriott. And nobody may ever be sold a room that doesn't exist."

Most candidates hear "booking system" and reach for the e-commerce inventory pattern: a rooms table, a row lock, decrement on purchase. It is the right instinct applied to the wrong noun. A hotel does not sell rooms. It sells room types — and a candidate who notices that in the first ten minutes builds a system with 1,460 inventory rows where the other candidate builds one with 80,300, and then spends the rest of the hour fighting a bin-packing problem they invented.

The second surprise arrives with the arithmetic. "Never oversell across nine thousand properties" sounds like a distributed-consensus problem, so that is what candidates design for. Then you do the estimation and discover the entire Marriott booking path peaks at 28 writes per second — a laptop handles it — while a single city search touches 6,300 inventory cells, and at peak the read path reaches 25.8 million cell reads per second. The hard problem was never the writes. It was search, and you could only have learned that from the napkin.

The Trap Built Into a Familiar Shape

Two failures show up in this question again and again:

• The Seat-Map Reflex: models inventory as physical rooms and assigns room 412 at booking time. It works, and it is how nobody does it — it forbids upgrades, strips the front desk of its ability to shuffle guests, and turns a counter decrement into bin packing. Signal: modelled the physical world instead of the sellable product.
• The Distributed-Transaction Maximalist: hears "never oversell" and reaches for global consensus, two-phase commit across the payment provider, an event log as the book of record — a planetary consistency protocol for a workload that peaks at 28 writes per second. Signal: never did the arithmetic, so never found the problem that was actually there.

The passing performance notices three things early: inventory is fungible, the workload is read-dominated by five orders of magnitude, and overselling is not a bug to be eliminated but a business parameter to be tuned — because hotels overbook on purpose, and a system that cannot is not safer, just less correct about the business it serves.