Hard · Travel and events
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. Practise this hard system design problem for free with a Google or GitHub account.
The brief
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.
Think of an airline's booking and seat system.
Users, scale and requirements
- Who uses it
- 20 million visitors a month (approx.)
- Audience in plain numbers
- 20,000,000 people per month
- Normal peak
- ≈ 6,000 requests per second
- Request mix
- Search: 58%; Read: 25%; Write: 6%; Payment: 2%; Sign-in: 6%; Notification: 3%
- Speed for 99 of 100 requests
- Search: ≈ 1,500 ms; Read: ≈ 750 ms; Write: ≈ 1,800 ms; Payment: ≈ 4,000 ms; Sign-in: ≈ 1,500 ms
- Successful requests
- 99.95%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $53,000
- Data at rest
- ≈ 4 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; Notification: 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; Personal data isolated; Tested backups
≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.
- About 3,500 fare searches a second at peak. Seat holds and changes are about 360 writes a second (approx.).
- A partner (global distribution) system provides some fares; limit about 200 requests a second.
- All numbers are rough approximations.
- Notification speed measures provider acceptance. Device receipt is outside this traffic model; check expiry, provider outcome and retries in the correctness trace before claiming delivery guarantees.
Questions that shape the design
Can two people hold the same seat?
Never. A seat is held by exactly one person, and holds expire after 15 minutes.
How heavy is a fare search?
Heavy. Most results can be reused for a few minutes, since fares move slowly, except during a sale.
What is the partner system limit?
About 200 requests a second, and during busy hours it can cut that in half without warning.
What records must we keep?
Passenger and payment records are sensitive. Every action must be audited, data encrypted, and backups proven to restore.
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.
09: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.
12:00 · Flash crowd
A scheduled launch brings a sudden rush of requests.
Traffic for Search, Read, Sign-in reaches 6 times the scheduled load; rises over 120 seconds, holds for 1,200 seconds and eases over 1,800 seconds. Other request types keep their scheduled load.
19:00 · Provider rate limit
An outside service lowers its configured request quota and answers 'too many requests' above the reduced limit.
Provider capacity falls to 50% of its configured quota. Duration: ≈ 3,600 seconds.
What a strong design has to handle
- Searching can use old answers. Holding a seat cannot. Where must the seat count live so two people cannot take the same one?
- Fence seat holds and resolve payments without exceeding partner fare quotas.
- Sync replication adds a few ms to every seat hold. It is the reason a failover cannot lose a booking.
- Caching fares for five minutes cuts partner calls by about 90 percent, and shows a price that may be a few minutes old. Re-check the price at checkout.
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
- Medium
Peer-to-peer wallet
People split dinner by sending each other money from their phones. A transfer takes money from one balance and adds it to another, and the sender must see the new balance right away. A flaky mobile connection often makes the app send the same transfer twice.
- Hard
Bank ledger
You run the system of record for a regional bank: every deposit, withdrawal and card settlement is a posting that must be exact and permanent. Customers in two continents read balances all day, and regulators can ask for proof at any time. A bad day for you is a loss of even one posting.
- Hard
Crypto exchange
People trade coins, check prices and withdraw funds around the clock from every continent. A sudden price crash makes everyone log in and trade at once, attackers flood you hoping to knock the site over, and a leaked key could empty a wallet. Balances must never be wrong.
- Easy
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.