Hotel Booking

Hotel Reservation

Design a hotel reservation system: guests search for rooms by place and dates, hold a room while they pay, and never get a room that someone else already has.

Overview

A hotel booking system sells nights in rooms. A guest searches a city for June 15 to 18, picks a hotel and a room type, and pays. The system must never promise the same room on the same night to two guests.

Two features make this different from an online shop. First, the thing sold is a room type on a date, not an item: a stay of three nights is three separate pieces of inventory that must all be free. Second, traffic is very lopsided. People search and compare far more often than they book, so searches must be cheap and may be a little stale, while the booking itself must be exact.

Guests do not usually pick room 412. They book a room type (a double with a city view), and the hotel assigns the room number at check-in. So the inventory is a count per room type per night, which keeps the hot data small.

Questions to ask first

How many hotels and bookings? — 1 million hotels, 1 million bookings a day
How much searching? — About 100 searches for every booking
Book a room type or a specific room? — A room type; the hotel assigns the room number
How far ahead can guests book? — Up to one year
Pay now or at the hotel? — Pay now: authorize the card when booking, capture later
Can the hotel oversell on purpose? — Yes, a small per-hotel allowance the hotel sets

What you will be able to do

Model inventory as one row per room type per night, and size it.
Book several nights at once without overselling, using a conditional update in one transaction.
Hold a room while the guest pays, and release it when they do not.
Make booking retries safe with an idempotency key.
Keep searches fast with a stale copy while booking stays exact.

Key concepts

Room-type inventory
One row per night
Conditional update
Row locks
Holds with expiry
Idempotency key
Authorize then capture
Search cache
Shard by hotel

Functional requirements

Search hotels by place, dates and number of guests, with prices
Show available room types and the total price for a stay
Hold a room type for the chosen nights while the guest pays
Confirm the reservation when payment succeeds; release it if not
Cancel a reservation and return its nights to inventory
Let hotels set room counts, prices and an overbooking allowance

Non-functional requirements

Never confirm more reservations for a night than the hotel allows
Search answers in under 500 ms at p99 (a target we chose); it may show availability up to a minute old
Booking answers in under 2 seconds, including the card authorization
A retried booking request never creates a second reservation or a second charge
Bookings stay available 99.99% of the time; search may degrade first

Interview questions

How do you stop double booking?
Why count rooms per room type instead of tracking each room?
Pessimistic or optimistic locking?
How long should a hold last, and what if the guest never pays?
Why may search show a room that is no longer free?
How do you shard this system?
How does payment fit without holding database locks?
What about cancellations and refunds?