Skip to content
System Designer

Medium · Travel and events

Hotel booking

You run a hotel booking site. People search for rooms, open hotel pages and book. Search can be a little behind, but you must never sell the last room twice. Bots copy your prices all day, and sometimes the payment company slows down. Practise this medium system design problem for free with a Google or GitHub account.

The brief

You run a hotel booking site. People search for rooms, open hotel pages and book. Search can be a little behind, but you must never sell the last room twice. Bots copy your prices all day, and sometimes the payment company slows down.

Think of a site like Booking.com.

Users, scale and requirements

Who uses it
30 million people a month (approx.)
Audience in plain numbers
30,000,000 people per month
Normal peak
≈ 8,000 requests per second
Request mix
Search: 45%; Read: 40%; Write: 8%; Payment: 2%; Sign-in: 5%
Speed for 99 of 100 requests
Search: ≈ 300 ms; Read: ≈ 400 ms; Write: ≈ 400 ms; Payment: ≈ 3,000 ms; Sign-in: ≈ 1,000 ms
Successful requests
99.9%
Data safety
No acknowledged write may be lost.
Monthly budget
≈ $12,000
Data at rest
≈ 3 TB
Where users are
North America: 60%; Europe: 40%
Home region
North America
Waiting deadlines
Search: 900 seconds; Read: 900 seconds; Write: 3,600 seconds; Payment: 3,600 seconds; Sign-in: 900 seconds
Fresh reads
People must see their own changes. At most 0.1% of reads may be stale in the model.
Personal reads
40% of reads are private; a shared public copy cannot answer them.
Required proofs
Managed encryption keys; Audit trail

≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.

  • Split peak traffic into searches, page views and booking steps using the request mix.
  • Room counts change when a guest books or cancels. Search results are a copy of them.
  • All numbers are rough approximations.

Questions that shape the design

Can search results be a little stale?

Yes, by a minute or so. A result that says "2 rooms left" may be out of date.

Can the final booking be stale?

No. The booking step must check the real count, so the last room is never sold twice.

How bad are the bots?

They send about half as much traffic again as real users, all day, mostly searches and page views.

Can a booking be paid later?

A room is held for 10 minutes while the guest pays. If the payment service is slow, the guest should see it quickly.

The traffic day

Consumer traffic, busiest in the evening. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

  1. 10:00 · Bot scraping

    Bots try stolen passwords and scrape pages, adding unwanted traffic.

    Extra attack traffic is 0.5 times the configured peak. Duration: ≈ 7,200 seconds.

  2. 15:30 · Slow dependency

    An outside service slows down. Your servers fill with requests waiting on it.

    Added response time: ≈ 3,000 ms. Duration: ≈ 1,800 seconds.

  3. 20:15 · Replication lag

    Copies fall behind. Users read old data, even their own fresh changes.

    Copy lag: ≈ 45 seconds. Duration: ≈ 1,200 seconds.

What a strong design has to handle

  • Searching and booking need different promises. Which one can use a slightly old copy, and which one must ask the real source?
  • Reserve room-night inventory atomically and reconcile payment against reservation ownership.
  • A search index is a second copy of your data. It makes search fast and means a result can show a room that was just taken.
  • A rate limiter set too tight blocks families on a hotel Wi-Fi who share one address; set too loose it lets scrapers through. Pick a limit from real traffic.

Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.

Concepts to practise

Related problems