A look at how Airbnb works. Airbnb runs a marketplace of 7 million listings across 220 countries, and the architectural challenge isn’t search or booking. It’s the consistency of the calendar. Two guests trying to book the same listing for overlapping dates must never both succeed. The architecture is built around preventing that race under millions of concurrent searches and bookings per day.
How Airbnb Works: The problem at scale
Airbnb is two products glued together: a search-heavy read path (guests browsing listings, 100M+ searches/day) and a write-heavy transactional booking path (reservations, payments, host messages, calendar updates). The two have completely different consistency requirements. Search can be eventually consistent (a listing showing as “available” when it was just booked 30 seconds ago is a small UX issue, easily corrected). Booking must be strictly consistent: overbooking the same night twice is a legal and reputational disaster.
The core architecture
Search path: the guest’s query hits the Search API, which uses Elasticsearch + geohash for spatial filtering (“listings within 5km of this point”) plus standard filters (dates, price, amenities). Results come from the search index (eventually consistent, refreshed every few minutes from the canonical store), with availability cross-checked against Redis calendar (per-listing availability cached as a bitset of bookable nights). Booking path: when a guest clicks “Reserve,” the Booking Service runs a two-phase transaction: phase 1 reserves the dates (pessimistic lock on the calendar rows, with a 30-minute hold), phase 2 confirms on payment success (releases or commits the reservation). Parallel to both, the Pricing ML service suggests per-night prices to hosts based on demand, seasonality, comparable listings, and historical booking patterns.
Two-phase booking is the consistency layer
The naive booking flow (“select dates, click book, pay, done”) fails the race condition: two guests could both see a listing as available for the same dates, both click book, both pay, and now you have two confirmed reservations for the same night. Airbnb’s solution is the reserve-then-confirm pattern: when the guest clicks “Reserve,” the system pessimistically locks those date rows for 30 minutes. Other guests searching for overlapping dates see the listing as unavailable (or limited-availability). If the first guest doesn’t complete payment within 30 minutes, the lock expires and the dates become available again. This is the same pattern airlines use for seat holds and hotels use for room blocks. It’s the only correct way to handle booking races at scale.
Dynamic pricing as an architectural surface
Airbnb’s Pricing ML isn’t a side feature. It’s first-class infrastructure. Hosts see a suggested per-night price whenever they list or update; many just accept it. The model considers hundreds of features: location, season, day-of-week, local events, comparable nearby listings, the host’s historical booking rate, and the listing’s own conversion rate. The result is that Airbnb’s listings are priced closer to market-clearing than hosts would set on their own, which directly drives booking volume. The model is retrained continuously; pricing signals flow back into the model as bookings confirm or fail.
The one non-obvious insight
Airbnb’s biggest architectural decision wasn’t technical. It was deciding that listings, not users, are the primary entity. Most marketplaces are user-centric (everything keyed off user_id). Airbnb is listing-centric: the listing is the unit of sharding (listings sharded by region), the unit of caching (per-listing calendar), the unit of pricing (per-listing suggestions). Users have many listings they can book, but every write goes through the listing. This is why the search and booking paths share infrastructure cleanly: both are listing-keyed.
Airbnb is a marketplace built around the calendar as a consistency boundary. Two-phase reserve-then-confirm prevents overbooking; dynamic pricing ML keeps listings near market-clearing; the listing (not the user) is the architectural primitive. Pattern worth studying for any marketplace.