Airbnb makes a standard booking problem harder because geo search, availability, pricing, booking flow, and trust all have to work together.
This chapter ties listing lifecycle, map search, messaging, reservation confirmation, payment rules, and abuse prevention into one architecture.
For interviews and engineering discussions, it is useful because it quickly shows whether you can reason about more than inventory: supply quality, safety, and varied user journeys matter too.
Geo Search
The map-driven search path needs to find candidates quickly without dragging heavy calendar checks and payment logic into every request.
Availability Calendar
The calendar can be projected and cached for search, but booking confirmation has to flow through a stricter correctness path.
Booking Path
A booking touches dates, money, reservation state, and notifications, so the confirmation path deserves to be designed as its own coordinated operation.
Trust & Fraud
A marketplace does not retain users on pretty search results alone: trust, checks, and fraud prevention are as core as booking itself.
Airbnb is not just a lodging search problem. It is a two-sided marketplace where geo search, availability calendars, booking, pricing, and trust all have to work as one system. A mistake in any of those paths quickly turns into lost conversion or a very real operational incident.
Source
Acing the System Design Interview
Zhiyong Tan includes a dedicated Airbnb design walk-through in the book.
Product scale
1Functional requirements
Guest journey
- •Search by location, travel dates, guest count, and stay rules
- •Filter by price, property type, amenities, and cancellation policy
- •View the listing page with photos, details, and reviews
- •Book, pay, and receive confirmation
- •Message the host before and after the stay
Host journey
- •Create and update listings, photos, and house rules
- •Manage the availability calendar and date restrictions
- •Configure pricing, discounts, and instant-book rules
- •Approve booking requests and communicate with guests
- •Receive payouts and handle post-stay reviews
2Non-functional requirements
Fast search
The map and search results should refresh almost instantly, or the experience stops feeling interactive.
High availability
Booking and stay-support paths cannot disappear during seasonal peaks or local failures.
Booking correctness
The same date range must not be confirmed for two guests just because a cache or search index is slightly stale.
At a high level, Airbnb splits the fast discovery path from the strict transactional path. Search lives under a hard latency budget, while booking must preserve calendar and payment correctness under competing requests.
System scale
3Geo search
Related topic
Proximity Service
Alex Xu's chapter is useful background on nearby lookup, spatial indexes, and geo filtering.
Geo search in Airbnb is more than a location lookup. After candidate retrieval, the system still has to apply availability checks and final ranking so the result set is both bookable and relevant.
Geo-indexing options
| Approach | Description | Best fit |
|---|---|---|
| Geohash | String encoding of coordinates that works well for prefix-based lookup | Simple queries and Redis-backed lookup |
| Quadtree ✓ | Recursively partitions the map into quadrants and fits in-memory search well | Fast candidate selection for search results |
| S2 Geometry | Hierarchical cells on the sphere, useful for global-scale geo products | Products closer to Google Maps scale |
| PostGIS | PostgreSQL extension with spatial indexes and SQL operators | Smaller systems with strong DB coupling |
How Airbnb search is usually structured
- 1Elasticsearch stores the searchable listing index with geo coordinates, filters, and textual fields.
- 2geo_bounding_box limits the search to the visible map viewport.
- 3A separate calendar service removes listings that are unavailable for the requested stay.
- 4The remaining candidates are re-ranked using personalization and business signals.
Sample Elasticsearch query
{
"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
That neighboring case goes deeper into how calendar models fail under concurrent reservations.
⚠️ Main difficulty
The calendar can be cached and replicated for search, but the booking confirmation point has to preserve strict correctness. You cannot confirm the same night for two guests just because the search results were a few seconds behind.
Data model
-- 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 when availability changes in blocks
- •Bitmap: pack booked days into bitmaps for fast checks
- •Caching: keep hot calendars in Redis near the search tier
- •Load isolation: separate hot listings from the long tail
As the product grows, the calendar almost always moves toward sharding by listing id or geographic segment. The key is to let search live on a read model while keeping booking confirmation on a narrow, well-controlled source of truth.
Syncing with search
Elasticsearch should not store the full calendar because it changes too often and becomes expensive to refresh. A common pattern is:
- 1The search index returns candidates based on map position, filters, and base metadata.
- 2The calendar service checks the requested date range in batch and removes unavailable options.
- 3The final candidate set is re-ordered using personalization and business signals.
5Booking path
Instant Book vs Request to Book
Instant Book
The guest is confirmed immediately, without manual host approval.
- + Fastest path to payment
- + Better conversion
- - More risk for the host
Request to Book
The host reviews the request before the booking is confirmed.
- + More control for hosts
- - Slower path for guests
- - Lower overall conversion
Instant-book flow
- 1Check availability: atomically verify the date range and place a lock via Redis SETNX or SELECT FOR UPDATE.
- 2Calculate price: combine nightly rates, fees, taxes, and discounts into the final total.
- 3Authorize payment: create a Stripe PaymentIntent and hold the amount without capturing it yet.
- 4Persist reservation: save the booking and update availability in one transaction.
- 5Send notifications: notify the guest and the host over email and push channels.
- 6Capture payment: turn the authorization into a capture according to product policy.
Distributed coordination
A reservation touches the calendar, payment, booking state, and notifications, so a Saga-style workflow is a natural fit: every step either commits or has a matching compensating action.
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
In Airbnb, price is not a static field on the listing card. It is its own subsystem with supply and demand signals. In dense cities and seasonal spikes, that pricing layer helps balance occupancy without making the product feel opaque to hosts or guests.
What the guest pays for
Set by the host
- Base nightly rate
- Weekend surcharges
- Weekly and monthly discounts
- Cleaning and extra-guest fees
Added by the platform
- Guest and host service fees
- Local taxes and mandatory charges
- Currency conversion and rounding
- Smart Pricing recommendations
Smart Pricing
Automated price recommendations usually combine several signal families:
- Seasonality
- Events in the city
- Day of week and booking lead time
- Occupancy of similar listings
- Lead time before the trip
- Competitor prices
- Rating and review quality
- Amenities and property type
- Photo and content quality
7Trust and safety
Airbnb cannot treat checkout as the whole product. It needs a trust-and-safety layer that verifies participants, protects communication, and detects abuse before the marketplace starts losing both sides at once.
Trust for both sides
For guests
- Verified listing photos and descriptions
- Reviews from other guests
- Superhost status
- Airbnb Cover and 24/7 support
- Clear cancellation and refund rules
For hosts
- Guest identity verification
- Review and behavior history
- Damage protection
- Security deposits and house rules
- Checks against abuse and gray-market behavior
Fraud detection
- •ML models: screen fake listings and suspicious reservations.
- •Risk scoring: users, payments, and bookings each receive their own risk score.
- •Message analysis: NLP helps catch attempts to move payment off platform.
- •Photo verification: CV models compare uploaded media with the promised property.
Review system
Two-sided reviews balance supply quality with predictability for the guest.
- •Blind reviews: each side sees the other review only after both submit or the window expires.
- •Limited window: reviews must be written within a fixed post-stay period.
- •Public response: the host can respond and add context for future guests.
8High-level architecture and standard scenarios
Architecture + Scenario Explorer
Discovery and booking paths for a two-sided marketplaceDiscovery Plane (read-heavy)
Transaction Plane (booking correctness first)
It is important to separate the search read path from the booking write path: discovery can live on indexes and projections, while booking has to flow through a stricter path of locking, payment handling, and state persistence.
9What to cover in an interview
✓ Must discuss
- •How to choose a geo index without collapsing it into the calendar model
- •How search, availability, and booking confirmation stay in sync
- •How to prevent double booking and races on hot listings
- •Why guests and hosts need different UX, constraints, and SLAs
- •How payment authorization differs from final capture
💡 Additional topics
- •Smart Pricing and its link to seasonality and competition
- •Search personalization and result diversity
- •Internationalization: currencies, languages, local taxes, and regulations
- •How the product grows from stays into experiences and adjacent categories
If time allows, it is worth mentioning the media path separately: originals live in storage, while resized variants are usually served through a CDN so they do not interfere with either search or booking traffic.
Common interview mistakes
- ✗Treat the case as a catalog problem and forget the second side of the marketplace
- ✗Keep the full calendar inside the search index
- ✗Ignore time zones and local stay-calculation rules
- ✗Skip trust, fraud, and user-generated-content quality entirely
Related chapters
- Hotel Booking System - A neighboring case about availability calendars, overbooking, and contention around scarce inventory.
- Acing the System Design Interview (short summary) - Useful for structuring marketplace answers without losing the product logic behind the architecture.
- System Design Interview: An Insider's Guide (short summary) - Covers practical patterns for geo search, indexing, and catalog scalability.
- Google Maps / Proximity Service - geosearch - Shows how to design nearby lookup, spatial indexing, and geo-ranked search.
- System Design case studies overview - Places Airbnb in the wider map of adjacent domains and architecture trade-offs.
- Uber/Lyft - Useful for comparing geo-heavy domains, candidate selection, and hard latency budgets.