System Design

Hotel Booking

Design a hotel room booking system like Booking.com or Expedia.

Functional requirements

• Travelers can search hotels in a city for a check-in and check-out date range and see which room types have at least one room free for every night of the stay.
• Travelers can reserve a room type for a date range; the system holds the inventory while they enter payment details and confirms the booking once payment succeeds.
• Travelers can view and cancel their bookings, and a cancellation returns the room nights to inventory immediately.
• Hotels can set the number of rooms per room type, close date ranges (e.g., block 10 rooms for a wedding party), and see who is booked on any given night.
• A booking records the nightly price shown at search time so the traveler pays what was quoted even if the hotel changes prices later.

Non-functional requirements

• Availability search is the critical path: p99 search latency under 300ms for a city and date range.
• Search results may be slightly stale (a room shown as free may have just been taken, and the reservation step then fails cleanly), but a confirmed booking is never wrong: two bookings can never hold the same room night.
• Holds, confirmations, and cancellations are strongly consistent and atomic against inventory, even under concurrent checkouts for the last room.
• Confirmed bookings are durable across any single machine or zone failure; a lost booking means a traveler arrives at a hotel with no room.
• Holds expire automatically after 10 minutes so abandoned checkouts return rooms, and one account cannot hold more than a few rooms at once, to prevent inventory squatting.

Scaling & constraints

• 500,000 hotels with ~2M room types and ~100 rooms per hotel on average; rooms are bookable up to 18 months ahead.
• 1.5M bookings per day, ~20/sec on average and ~100/sec at peak; the average stay is 2.5 nights.
• Read:write ratio is about 500:1: roughly 750M availability searches per day, each covering every hotel in a city (up to ~5,000) for every night of the stay.
• An inventory record (hotel, room type, night, rooms available) is ~100 bytes; a booking record is ~2 KB.
• Demand is spiky and hotel-specific: a conference or concert announcement can send 1,000+ concurrent checkouts to one hotel for the same dates within a minute.
• Booking records are retained for 7 years; 30% of holds are abandoned before payment completes and 10% of confirmed bookings are later canceled.

Out of scope

• Dynamic pricing, promotions, and loyalty programs.
• Payment processing beyond receiving a success or failure callback.
• Search ranking, filters, photos, and reviews.
• Synchronization with hotels' own property management systems and other booking channels.