Easy · Travel and events
Restaurant reservations
Diners look up restaurants, check which tables are free tonight and book one. Looking is easy to speed up. Booking is not: two people must never get the same table. Friday at 5 pm is the busy moment. Practise this easy system design problem for free with a Google or GitHub account.
The brief
Diners look up restaurants, check which tables are free tonight and book one. Looking is easy to speed up. Booking is not: two people must never get the same table. Friday at 5 pm is the busy moment.
Think of a booking site like OpenTable.
Users, scale and requirements
- Who uses it
- 6 million diners a month (approx.)
- Audience in plain numbers
- 6,000,000 people per month
- Normal peak
- ≈ 1,500 requests per second
- Request mix
- Read: 80%; Write: 15%; Sign-in: 5%
- Speed for 99 of 100 requests
- Read: ≈ 500 ms; Write: ≈ 500 ms; Sign-in: ≈ 1,000 ms
- Successful requests
- 99.9%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $2,500
- Data at rest
- ≈ 0.3 TB
- Where users are
- North America: 80%; Europe: 20%
- Home region
- North America
- Waiting deadlines
- Read: 900 seconds; Write: 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.
≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.
- Estimate bookings from the write share at the Friday peak.
- One app server handles about 1,000 requests a second (approx.).
- All numbers are rough approximations.
Questions that shape the design
Can the list of free times be a little old?
Yes, by a minute. If a time has just gone, the booking step says so politely.
Can the booking step be old?
No. The final check must use the real table count, so a table is never given out twice.
How many people look compared with people who book?
About 5 people look for every 1 who books (approx.).
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.
17:00 · Flash crowd
A scheduled launch brings a sudden rush of requests.
Traffic reaches 3 times the scheduled load; rises over 30 seconds, holds for 900 seconds and eases over 1,800 seconds.
12:10 · Cache stampede
The cache empties (restart, purge, mass expiry) and every request rushes to the database at once.
Recovery window: ≈ 300 seconds.
What a strong design has to handle
- Looking and booking need different promises. Which can use an old copy and which cannot?
- A longer cache time saves the database, but shows tables that are already gone. A minute is a good middle.
- One database that serializes bookings is simple and correct. Spreading bookings over many databases needs care to keep the promise.
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
- Easy
Shopping cart
Shoppers browse products, drop things in a cart and come back later from another phone. Browsing is most of the traffic and can be a little old. The cart itself must always show what the shopper just added.
- Medium
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.
- Hard
Airline booking
You run the booking system for an airline. Fare searches are heavy, seats are limited, and every flight needs the right number of tickets, no more and no fewer. You depend on a partner system for fares from other airlines, and it has strict limits. A fare sale and a slow partner will both happen on the same day.
- Easy
URL shortener
People paste a long web address and get back a short one. Millions of other people then tap that short link, so reading is almost everything. Keep every tap fast, and never lose a link.