Design Airbnb
Design Airbnb with search (dates + location), booking system, pricing engine, and reviews.
Quick answer: Design Airbnb
Design Airbnb is covered here as a practical system design interview problem. Design Airbnb with search (dates + location), booking system, pricing engine, and reviews. Use it to practice requirements, APIs, storage choices, scaling bottlenecks, data consistency, observability, and failure handling for a medium interview round.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
Problem Statement
Design a vacation rental marketplace like Airbnb where hosts list properties and guests search by location, dates, and filters, book stays, and leave reviews. The system must handle complex availability queries (intersection of date ranges with location), prevent double-bookings, and support dynamic pricing.
Requirements
Functional
- Search listings by location (map viewport), check-in/check-out dates, guest count, and filters (price, amenities, property type)
- Book a listing for specific dates with instant booking or host approval flow
- Dynamic pricing: hosts set base price; system suggests prices based on demand, seasonality, and local events
- Reviews: guests and hosts review each other after checkout (double-blind reveal)
Non-Functional
- Latency: Search results in <1 second with 20+ results per page
- Consistency: Double-booking prevention requires strong consistency on reservations
- Scale: 7M active listings, 150M users, 2M bookings/day, peak 500K concurrent searches
- Availability: 99.99% for search, 99.95% for booking
Core Architecture
-
Search Service -- Combines geospatial and temporal filtering. Uses Elasticsearch with geo_bounding_box for location and a custom availability check. Pre-indexed listings include amenities and property attributes. Availability is checked against a calendar service for the top 200 candidates (not all listings). Results are ranked by relevance, price, and listing quality score.
-
Availability Calendar Service -- Each listing has a calendar stored in PostgreSQL: one row per date per listing (listing_id, date, status: available/booked/blocked, price). Availability queries use:
WHERE listing_id = ? AND date BETWEEN ? AND ? AND status = 'available'. Count of available dates must equal the stay length. Bookings lock the date range with SELECT ... FOR UPDATE. -
Booking Service -- Orchestrates the reservation: (1) Check availability with row-level locks, (2) Create reservation record with status PENDING, (3) Charge guest via payment gateway, (4) Update calendar dates to BOOKED, (5) Notify host. If payment fails, release locks and mark reservation CANCELLED. Uses idempotency keys to prevent duplicate bookings from retries.
- Pricing Engine -- Suggests nightly prices to hosts using an ML model trained on: local demand (search volume for area + dates), seasonality (holidays, events), comparable listings' occupancy rates, and day-of-week patterns. Hosts can accept, adjust, or ignore suggestions. Smart pricing auto-adjusts daily if enabled.
Database Choice
PostgreSQL for listings, users, reservations, reviews, and the availability calendar -- ACID transactions essential for booking integrity. The calendar table is partitioned by listing_id for locality. Elasticsearch for search -- geospatial queries with faceted filtering (price ranges, amenities, property type). Redis for search result caching (keyed by query hash, 60-second TTL) and session storage. S3 + CDN for listing photos.
Key API Endpoints
GET /api/v1/search?lat=37.77&lng=-122.42&checkin=2024-03-01&checkout=2024-03-05&guests=2&min_price=50&max_price=200
-> Returns: \{ listings: [\{ id, title, price_per_night, rating, thumbnail_url, coordinates \}], total: 342 \}
POST /api/v1/reservations
-> Body: \{ listing_id: "L-123", checkin: "2024-03-01", checkout: "2024-03-05", guests: 2, payment_method_id: "PM-7" \}
-> Returns: \{ reservation_id: "R-456", status: "CONFIRMED", total: 680.00 \}
POST /api/v1/reviews
-> Body: \{ reservation_id: "R-456", rating: 5, comment: "Amazing stay!" \}
Scaling Insight
The two-phase search strategy is essential for performance. Phase 1: Elasticsearch returns the top 200 listings matching location and attribute filters (sub-100ms, no availability check). Phase 2: the Availability Calendar Service checks date availability only for these 200 candidates (parallel batch query to PostgreSQL). This avoids the impossible task of checking availability for all 7M listings on every search and keeps end-to-end search latency under 1 second.
Key Tradeoffs
| Decision | Option A | Option B | Chosen |
|---|---|---|---|
| Availability storage | Bitmap per listing (compact) | Row per date per listing (flexible) | Row per date -- enables per-night pricing, blocked dates, and simple SQL queries |
| Search + availability | Single query (Elasticsearch + calendar) | Two-phase (ES then calendar) | Two-phase -- keeps ES index simple, calendar check only for top candidates |
| Booking model | Instant booking only | Instant + host approval | Both -- instant for most listings, approval for premium/long-stay to give hosts control |
Original DosiBridge notes for Design Airbnb
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Design Airbnb is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Core Entity: For Design Airbnb, decide the core entity before choosing tools; otherwise the design looks clean but fails when airbnb changes.
- Read/Write Path: For Design Airbnb, decide the read/write path before choosing tools; otherwise the design looks clean but fails when airbnb changes.
- Contention Point: For Design Airbnb, decide the contention point before choosing tools; otherwise the design looks clean but fails when airbnb changes.
- Abuse Path: For Design Airbnb, decide the abuse path before choosing tools; otherwise the design looks clean but fails when airbnb changes.
- Recovery Workflow: For Design Airbnb, decide the recovery workflow before choosing tools; otherwise the design looks clean but fails when airbnb changes.
Design Airbnb correctness boundary
For this problem, separate the user-visible action from background work. The correctness boundary is the smallest state transition that must not be duplicated, lost, or reordered. Naming that boundary makes the solution more original than a stock API/database/cache template.
Design Airbnb scaling bottleneck
The first bottleneck should be described in the language of this system: a hot timeline, a contested seat, a busy wallet ledger, a media-processing queue, or a search index update delay. That bottleneck decides which component deserves the deepest interview discussion.
Production review question
If Design Airbnb suddenly receives 10x traffic, which entity becomes contested first, and what queue, lock, shard, or cache protects that entity without hiding correctness bugs?
Practical metric to track
Track airbnb health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Design Airbnb, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.