Airbnb Booking Platform – System Design Interview Preparation

Practice designing a booking platform like Airbnb. Cover search, availability, payments, reviews, and real-time messaging between hosts and guests.

This is a full mock interview round, not a written solution to read through. The AI interviewer poses the Airbnb design problem, pushes back on your choices, and asks the follow-up questions a real interviewer would: how the system behaves as traffic grows, where the bottlenecks move, which consistency guarantees you are trading away, and what happens when a component fails. You get structured feedback and a score on requirement gathering, high level architecture, data modelling, scalability and communication at the end of every attempt.

Designing Airbnb is a recurring question in High Level Design (HLD) rounds at Google, Amazon, Meta, Microsoft, Netflix and Uber, and at high-growth product companies hiring SDE-2 and above. Working through it out loud - repeatedly, under time pressure - is what separates candidates who know the components from candidates who can defend a design.

What this question is really testing

Availability search over date ranges - an interval problem, not a boolean - and preventing double bookings on overlapping ranges.

Scale to establish before drawing anything

7M listings, searched by location and date range with filters; search is the dominant read path.
Bookings are comparatively rare, which means the system is read-optimised with a narrow, strict write path.
Availability per listing per night for a year is 365 rows - small per listing, large across the catalogue.

Core components

Search service – Geospatial plus date-range availability plus filters. The hardest query in the system.
Availability store – Per-listing calendar. Modelled per night or as intervals, and that choice drives everything.
Booking service – Reserves a range atomically, which is where overlap must be impossible.
Pricing service – Per-night dynamic pricing composed with length-of-stay and seasonal rules.
Messaging and review services – Separate domains that attach to a booking.

Trade-offs to defend

Per-night rows versus interval records – Per-night is simple to query and large to store; intervals are compact and make overlap checks harder. Pick one and show the overlap check.
Instant book versus host approval – Approval introduces a pending state that holds dates without confirming them, which is the same hold problem in a different costume.
Search freshness – A listing booked seconds ago still appearing in search results is acceptable; letting it be booked twice is not. The guarantee belongs at write time, not search time.

Follow-up questions to expect

Two guests book 10-15 March and 13-18 March at the same instant. What makes one fail?
Search for "Goa, 4 nights, pool, under 5000" across 7M listings in 200ms. What is indexed and where?
A host blocks dates that are already booked. What happens?