Airbnb adds another layer on top of booking complexity: user-generated content, host-generated supply, trust mechanisms, and geo search.
The case helps connect listing lifecycle, availability calendars, ranking, messaging, pricing, and booking flow into a two-sided marketplace architecture.
For interviews and design reviews, it is useful because it shows whether you can reason about more than inventory: trust, supply quality, and the diversity of user journeys also matter.
Business Correctness
Maintain valid order/booking state under retries, races, and partial failures.
User Experience
Protect critical user flows during burst traffic and dependency degradation.
Transactional Boundaries
Specify where strong consistency is mandatory vs where eventual is acceptable.
Evolution Path
Show how architecture evolves from MVP to high-scale and multi-region setups.
Designing Airbnb is a classic System Design interview task that brings together geosearch, availability management, dynamic pricing and trust system. It is a two-sided marketplace with unique technical challenges.
Source
Acing the System Design Interview
A detailed analysis of Airbnb design is in the book by Zhiyong Tan.
Key Features of Airbnb
1Functional Requirements
Guest Flow
- •Search by location, dates, number of guests
- •Filtering (price, type of housing, amenities)
- •View listing with photos and reviews
- •Booking and payment
- •Messenger with host
Host Flow
- •Creating and editing a listing
- •Manage your availability calendar
- •Setting up pricing rules
- •Confirmation/rejection of bookings
- •Receiving payments
2Non-functional requirements
Low Latency Search
Geosearch < 200ms. Users expect instant results when changing a map.
High Availability
99.99% uptime. Bookings mean money, downtime is unacceptable.
Consistency
You can't sell the same night twice. Strong consistency for bookings.
System scale
3Geo Search: Search by location
Related topic
Proximity Service
Alex Xu discusses geosearch in detail in the chapter on Proximity Service.
Approaches to geoindexing
| Approach | Description | Use Case |
|---|---|---|
| Geohash | String representation of coordinates, prefix matching | Redis, simple queries |
| Quadtree ✓ | Recursive division of space into 4 parts | In-memory search, Uber |
| S2 Geometry | Google's library, hierarchical cells | Google Maps, Foursquare |
| PostGIS | PostgreSQL extension with R-tree indexes | Small scale |
Airbnb Search Architecture
- 1Elasticsearch as the main search engine with geo_point type
- 2geo_bounding_box query for the visible area of the map
- 3Availability filter - join with availability calendar
- 4Ranking — ML model for personalizing results
Elasticsearch Query Example
{
"query": {
"bool": {
"filter": [
{
"geo_bounding_box": {
"location": {
"top_left": { "lat": 40.73, "lon": -74.1 },
"bottom_right": { "lat": 40.01, "lon": -73.12 }
}
}
},
{ "term": { "property_type": "entire_home" } },
{ "range": { "price": { "gte": 50, "lte": 200 } } },
{ "range": { "guests": { "gte": 2 } } }
]
}
}
}4Availability Calendar
Related case
Hotel Booking
A similar problem of availability management is discussed in the Hotel Booking case.
⚠️ Main difficulty
The calendar must be eventually consistent for reading (search), but strongly consistent for writes (booking). You can't sell the same night twice!
Data Schema
-- Calendar by day
CREATE TABLE availability (
listing_id UUID,
date DATE,
status ENUM('available',
'blocked', 'booked'),
price DECIMAL,
min_nights INT,
PRIMARY KEY (listing_id, date)
);
-- Search index
CREATE INDEX idx_available
ON availability(date, status)
WHERE status = 'available';Optimizations
- •Date ranges: Store intervals instead of individual days
- •Bitmap: 365 bits per year, fast operations
- •Caching: Redis for hot listings
- •Sharding: By listing_id for isolation
Synchronization with search
Elasticsearch should not store the full calendar because it changes too often. Instead, a two-step approach is used:
- 1ES returns candidates by geo + filters
- 2Availability Service filters by calendar (batch lookup)
- 3Ranking Service sorts the final results
5Booking Flow: Reservations
Instant Book vs Request to Book
Instant Book
The guest books immediately, the host does not confirm.
- + Best UX for guests
- + Higher conversion
- - Risk for hosts
Request to Book
The host must confirm the booking.
- + Control for hosts
- - Delay for guests
- - Lower conversion
Booking Process (Instant Book)
- 1Check availability: Atomic check + date locking (Redis SETNX or SELECT FOR UPDATE)
- 2Calculate price: Base price + cleaning fee + service fee + taxes
- 3Payment authorization: Stripe PaymentIntent (hold, not charge)
- 4Create reservation: Transaction: booking + update availability
- 5Notifications: Email/push to guest and host
- 6Payment capture: Charge after check-in (or 24h before)
Distributed Transactions
A reservation touches several services. The Saga pattern is used:
Saga: CreateBooking
├── Step 1: Reserve dates (Availability Service)
│ └── Compensate: Release dates
├── Step 2: Authorize payment (Payment Service)
│ └── Compensate: Cancel authorization
├── Step 3: Create booking (Booking Service)
│ └── Compensate: Delete booking
└── Step 4: Send notifications (Async, no compensate)6Dynamic Pricing Engine
Price components
Host sets:
- Base nightly rate
- Weekend pricing
- Weekly/monthly discounts
- Cleaning fee
- Extra guest fee
Airbnb adds:
- Service fee (guest): ~14%
- Service fee (host): ~3%
- Occupancy taxes
- Currency conversion
Smart Pricing (ML)
Airbnb offers hosts automatic pricing based on:
- Seasonality
- Events in the city
- Day of the week
- Occupancy rate
- Lead time
- Competitors
- Rating
- Amenities
- Photo quality
7Trust & Safety System
Two-way trust
For guests:
- Verified photos
- Reviews from other guests
- Superhost badge
- Airbnb Cover (insurance)
- 24/7 support
For hosts:
- ID verification
- Guest reviews
- Damage protection
- Security deposit
- Background checks
Fraud Detection
- •ML models: Detection of fake listings and suspicious bookings
- •Risk scoring: Each user and transaction receives a risk score
- •Message scanning: NLP for off-platform payments detection
- •Photo verification: CV to check whether the photo matches reality
Review System
Two-way feedback is the key to trust. Key mechanics:
- •Blind reviews: Both see reviews only after both have written
- •14-day window: Limited time to write a review
- •Response: The host can respond to the review publicly
8High-Level architecture and standard scenarios
Architecture + Scenario Explorer
Discovery and booking paths for a two-sided marketplaceDiscovery Plane (read heavy)
Transaction Plane (consistency first)
It's important to separate search read-path and booking write-path: discovery can be eventually consistent, while booking operations must go through a strict transactional path with locking and payment orchestration.
9Key interview points
✓ Be sure to discuss
- •Geo search: index selection (Geohash vs Quadtree vs S2)
- •Availability: how to synchronize with search
- •Double booking prevention: locking strategy
- •Two-sided marketplace: different UX for guest/host
- •Payment flow: authorization vs capture
💡 Additional topics
- •Smart Pricing ML model
- •Search ranking personalization
- •Photo storage and CDN
- •Internationalization (currencies, languages)
- •Experiences (not just accommodation)
Common interview mistakes
- ✗Forget about the two-way nature of the marketplace (guest + host flows)
- ✗Store availability in search index (changes too often)
- ✗Ignore timezone issues for calendar
- ✗Do not discuss trust & safety for the marketplace
Related chapters
- Hotel Booking System - Compare inventory modeling and anti-overbooking strategies.
- Acing the System Design Interview (short summary) - Interview framing for marketplace trade-offs and communication.
- System Design Interview: An Insider's Guide (short summary) - Core patterns for geosearch, indexing, and listing scalability.
- Google Maps / Proximity Service - geosearch - Nearby search and geo-ranking patterns for map-driven UX.
- System Design case studies overview - Cross-case map of adjacent domains and architecture decisions.
- Uber/Lyft - Compare real-time geodomains, matching, and latency budgets.