System Design Problems
Design Airbnb
Airbnb serves 150M+ users across 220+ countries with 7M+ listings. This design covers search with geo-filtering, booking with availability management, reviews, and payment processing.
- Scale β 150M+ users, 7M+ listings, 1B+ nights booked
- Search β Geo-filtered search with 100ms latency
- Booking β Double-booking prevention with distributed locks
Airbnb's core challenge is building a two-sided marketplace with trust, search, and real-time availability.
Requirements Clarification
Functional Requirements
- Search listings by location, dates, and filters
- View listing details with photos and reviews
- Book accommodations with availability check
- Leave reviews and ratings
- Messaging between hosts and guests
- Payment processing with escrow
- Host management dashboard
Non-Functional Requirements
- Availability: 99.99% uptime
- Latency: Search results < 500ms
- Consistency: Strong for bookings (no double-booking)
- Scale: 150M users, 100K searches/minute
Airbnb's critical constraint: No double-booking. Unlike social media where eventual consistency is acceptable, a booking conflict destroys trust. This requires strong consistency for the booking path.
Back-of-the-Envelope Estimation
Search QPS
Here,
- =Searches per minute
- =Queries per second
Storage Estimation
Listing data:
- 7M listings x 10KB metadata = 70 GB
- 7M listings x 50 photos x 2MB = 700 TB (object storage)
Review data:
- 200M reviews x 2KB = 400 GB
Booking data:
- 1B bookings x 1KB = 1 TB
High-Level Architecture
Search Architecture
DfGeo-Filtered Search
Airbnb's search uses Elasticsearch with geo-point queries. Listings are indexed by location using a quadtree structure. The search supports filtering by price, amenities, ratings, and availability.
Geo Distance Query
Here,
- =Earth radius (6371 km)
- =Latitude
- =Longitude
Booking System: Preventing Double-Bookings
DfPessimistic Locking with Optimistic Fallback
Airbnb uses a two-phase approach: (1) Redis distributed lock on listing+dates prevents concurrent bookings, (2) Database unique constraint on (listing_id, date) as fallback, (3) If both fail, reject the booking.
Availability Check
Here,
- =Listing ID
- =Requested date range
- =Existing booking
Optimistic locking alone is insufficient for high-contention scenarios (popular listings during peak season). The Redis distributed lock prevents the thundering herd problem.
Trust and Safety
DfTwo-Sided Review System
Airbnb uses a two-sided review system where both host and guest review each other. Reviews are published simultaneously after both parties submit or after 14 days. This prevents retaliatory reviews.
Data Model
Booking Schema
Here,
- =Unique booking identifier
- =Date range
- =pending/confirmed/completed/cancelled
Practice Exercises
- Search: Design a search system that returns results in < 100ms for 100K QPS.
- Availability: How would you handle a situation where two guests try to book the same listing at the exact same time?
- Payments: Design an escrow system where payment is held until checkout.
- Scale: How would you handle a flash sale where 100K users search for the same city simultaneously?
Key Takeaways:
- Search uses Elasticsearch with geo-point indexing
- Booking requires distributed locks to prevent double-booking
- Two-sided review system builds trust
- Escrow payment model protects both hosts and guests
- Geo-filtered search is the core query pattern
What to Learn Next
-> Design Uber Real-time location and dispatch.
-> Design Amazon E-commerce at scale.
-> Idempotency Handling duplicate requests.
-> Saga Pattern Distributed transactions.
-> Outbox Pattern Reliable event publishing.
-> Circuit Breaker Preventing cascade failures.