Design Airbnb
Geospatial property listing engine with search bounding filters and calendar availability grids.
1. System Requirements
- Hosts list property profiles with locations and pricing.
- Users search properties within a bounding map area.
- Display property availability calendar grids.
- Book stays for selected check-in/check-out dates.
- Low-latency geospatial property searches (< 200ms).
- Strong consistency for reservation dates (no double booking).
- High availability for browsing listings.
2. Scale & Resource Estimates
Throughput: 5 Million properties, 100 Million daily active searches. 100,000 reservations booked per day.
Storage & RAM: Property descriptions and listing photos: 5M listings * 5MB media assets = 25 Terabytes total.
3. System API Endpoints
// 1. Search properties within bounds
GET /api/v1/search?lat_min=40.7&lat_max=40.8&lon_min=-74.0&lon_max=-73.9&checkin=2026-08-01&checkout=2026-08-07
Response: { listings: [ { listing_id: "lst-9902", price: 150, location: [40.7128, -74.0060] } ] }
// 2. Book listing stay
POST /api/v1/reservations
Request: { listing_id: "lst-9902", check_in: "2026-08-01", check_out: "2026-08-07", user_id: "usr-441" }
Response: { reservation_id: "res-3304", status: "confirmed" }4. Database Schema Design
Table: listings (PostgreSQL + PostGIS geospatial index)
- listing_id (UUID - Primary Key)
- host_id (UUID)
- geo_location (GEOMETRY(Point, 4326))
- price_per_night (NUMERIC)
Table: reservations (PostgreSQL - sharded by listing_id)
- reservation_id (UUID - Primary Key)
- listing_id (UUID - Sharding Key)
- check_in (DATE)
- check_out (DATE)
- user_id (UUID)5. Interactive High-Level Architecture
6. Scalability Deep Dive & Bottlenecks
Implements **geospatial bounding box filters**. Property coordinates are indexed in Elasticsearch using Geo-Point schemas. Searches specify lat/lon bounds, and Elasticsearch filters active listings inside the polygon. For availability verification, calendar dates are stored in PostgreSQL as date range indices. A booking query uses Postgres overlaps syntax (`daterange(check_in, check_out) && booked_range`) to verify date availability.
7. Production Scaling Strategies
Search Geo-Sharding: Shard Elasticsearch indices by region (US-West, US-East, EU, Asia). Each shard holds ~2M listings. Geo-queries only hit the relevant regional shard. Cross-region searches fan out to multiple shards and merge results by relevance score.
Calendar Availability Index: Each listing's calendar is stored as a bitmap (365 bits = 1 year, 1 = booked, 0 = available). Availability checks are O(1) bitwise AND operations. Stored in Redis for hot listings (top 20%), PostgreSQL for the rest.
Dynamic Pricing ML: A pricing model (gradient-boosted trees) runs nightly per-listing, considering: seasonality, local events, competitor pricing, demand forecast. Suggested prices cached in Redis. Hosts can override via manual pricing rules.
Booking Consistency: Double-booking prevention via PostgreSQL serializable isolation on the calendar table. If two guests try to book overlapping dates, only the first transaction commits. The second gets a conflict error and retries with updated availability.
Review Pipeline: Reviews are indexed in Elasticsearch for full-text search and sentiment scoring. A moderation ML model flags potentially fake reviews (similarity detection, reviewer behavior patterns). Flagged reviews are queued for human review.
Image Optimization: Hosts upload 20-50 photos per listing. Each is resized to 8 variants (thumbnail → full-res). Served from CDN with WebP format for modern browsers, JPEG fallback. Lazy-loading on listing pages reduces initial page load by 70%.
8. Runnable Production Starter Code
Scaffold