Airbnb Search & Availability Architecture

The first search stage uses Elasticsearch with geo_distance queries to find listings within the user's map viewport or search radius. Elasticsearch indexes listings with their latitude/longitude, enabling efficient bounding-box and geo-distance filtering. Additional hard filters (price range, guest count, property type, dates) are applied as Elasticsearch query clauses to prune the candidate set from millions to a few thousand. The Elasticsearch cluster is sharded by geographic region, with replicas for both fault tolerance and read throughput. Index updates propagate within seconds when hosts modify listings.

After candidate retrieval, Airbnb applies a multi-stage ranking pipeline. The first stage is a lightweight model (gradient-boosted decision tree) that scores thousands of candidates in under 10ms. The second stage is a deep neural network that re-ranks the top ~100 candidates using 1,000+ features including listing quality signals, personalization features (user search history, saved listings), and business objectives (conversion probability, revenue potential). This two-stage approach balances computational cost with ranking quality — the expensive neural model only scores the most promising candidates.

The ranking models consume features from Airbnb's centralized feature store, which serves both real-time and precomputed features with sub-5ms latency. Real-time features include the user's current session behavior (clicks, views, filters applied), listing-level signals (recent booking rate, response time), and contextual features (time of day, device type, trip purpose). Precomputed features — like a listing's historical conversion rate and average review score — are updated via batch pipelines and cached in a low-latency key-value store. The feature store ensures training/serving consistency, preventing training-serving skew.

Each listing has a real-time availability calendar that reflects the host's blocked dates, existing reservations, minimum stay requirements, and pricing rules. The calendar service is a dedicated microservice backed by a strongly-consistent database — showing an unavailable listing in search results wastes user attention and erodes trust. When a booking is confirmed, the calendar is updated synchronously before the booking confirmation is returned. Search results are cross-referenced against the calendar service after ranking, filtering out any listings that became unavailable between indexing and query time.

Airbnb runs hundreds of concurrent A/B experiments on search ranking. The primary metric is 'bookings per search' but the team also tracks downstream metrics like guest satisfaction, host earnings, and long-term retention. Each experiment modifies a specific aspect of the ranking pipeline — feature weights, model architecture, diversity injection rules, or business objective weightings. Interleaving experiments (showing results from two models alternately within the same search) provide faster signal than traditional A/B splits. A 1% improvement in search relevance translates to measurable revenue impact at Airbnb's scale.