System Design Interview
Home and hotel booking inspired by Airbnb and Booking.com: a search index of location, price and available nights kept current from change logs, nightly availability claimed in one transaction with a conditional update, holds that expire, idempotent payment, photos on a CDN, cached listing pages, and booking notifications. A teaching design.
See why a SQL query over location and every night's availability can't serve search.
What was missing: Nothing yet.
Why that's risky: A search for "Goa, these 3 nights, 4 guests, under ₹8,000" joins millions of listings with every night's availability. Searches outnumber bookings 50 to 1, and they all hit the same database that takes bookings.
What gets added: One server and one database that store listings, nightly availability and reservations, and answer searches with a SQL query.
Trade-offs: One consistent database, at the cost of every search competing with every booking.
Move search to an index built for it, and keep bookings correct in the database.
What was missing: Search ran as SQL against the bookings database.
Why that's risky: Photos come from the app servers, every listing page reads the database, and nothing stops a guest from holding a home while their payment fails.
What gets added: A search index with each listing's location (geohash), price, amenities and a bitmap of available nights, kept current from the databases' change logs. Bookings claim every night of the stay in one transaction with a conditional update, so two guests can never get the same night.
Trade-offs: The index lags the database by a second or two. Search re-checks the top results' availability, and the booking transaction is the final word.
Serve the heavy, read-mostly parts of the page cheaply.
What was missing: Photos and listing pages came from the servers and the database on every view.
Why that's risky: Booking still has no payment step, so a home can't be held while a guest pays, and nobody is told about a booking.
What gets added: Photos in object storage in several sizes, served through a CDN, and a cache of rendered listing pages refreshed when the host edits them.
Trade-offs: A host's edit can take a moment to appear while the cache refreshes.
Hold a home while the guest pays, and never charge for nights that weren't secured.
What was missing: No payment step and no notifications.
Why that's risky: One load balancer, no protection from scrapers hammering search, and no view of booking conflicts or payment failures.
What gets added: Booking first places a hold on every night in one transaction, then takes payment with an idempotency key, then confirms. A hold that isn't paid within 10 minutes is released. Confirmed, cancelled and expired bookings go onto a queue, and a worker emails and notifies guest and host.
Trade-offs: A held home is unavailable to others for up to 10 minutes even if the guest walks away. That's the price of never charging for a stay that can't be honoured.
Survive a holiday-weekend rush and keep scrapers out.
What was missing: One load balancer, nothing stopping scrapers, and no view of conflicts or index lag.
Why that's risky: Remaining risk is low. A very popular home on a holiday weekend still sees many failed booking attempts, but each fails fast and correctly.
What gets added: A rate limiter on searches per IP and bookings per account, a second load balancer, index replicas, more service instances, a replicated bookings database, and monitoring of search latency, index lag, booking conflicts and payment failures.
Trade-offs: Searches may show a home that was booked a second ago. The booking transaction catches it, which is cheaper than keeping the index perfectly current.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
