Airbnb System Design: The Hard Parts
Airbnb looks like a listings website: search, view, book. The difficult parts are hidden:
- Search must rank millions of listings by what each guest is likely to book, filtered by dates, price and location.
- Availability must never let two guests book the same night.
- Payments move money across countries, currencies and hosts, and must never charge twice.
This post walks through each, using what Airbnb's engineers have published, plus the standard interview design.
🎯 Quick Answer (30-Second Read)
- Search: a geo-aware search index filtered by dates and price, then ranked by machine learning (Airbnb has published papers on deep learning and embeddings for search).
- Availability: a calendar per listing; bookings use transactions or locks so the same nights can't be sold twice.
- Booking flow: reserve dates, take payment, confirm, as a state machine with timeouts.
- Payments: Airbnb built an idempotency framework to avoid double payments across its distributed services.
- Architecture: Airbnb migrated from a Ruby on Rails monolith ("Monorail") to a service-oriented architecture.
High-Level Architecture
location, amenities, price")] SEARCH --> RANK["ML ranking"] SEARCH --> AVAIL API --> LIST["Listing service"] API --> AVAIL["Availability /
calendar service"] API --> BOOK["Booking service
(state machine)"] BOOK --> AVAIL BOOK --> PAY["Payments
(idempotent)"] PAY --> PSP["Payment processors,
payouts to hosts"] BOOK --> EVT[["Events"]] --> NOTIF["Notifications,
messaging, reviews"]
1. Search and Ranking
Search runs in two steps:
- Retrieve: find listings in the map area that match filters (guests, dates available, price).
- Rank: order them by how likely this guest is to book and have a good stay.
Airbnb has published how it moved from hand-tuned scoring to gradient-boosted trees and then deep neural networks for search ranking, and how it trained listing embeddings from users' click sessions to find similar listings. Ranking also has to balance the guest's interests with fairness to hosts and overall marketplace health.
2. Preventing Double Bookings
Two guests try to book the same apartment for the same nights at the same moment. Only one can win.
Common techniques:
- One row per listing-night with a unique constraint, so the database itself rejects a second booking of the same night
- Row locks (
SELECT ... FOR UPDATE) or optimistic locking with version numbers - Short holds: dates are held for a few minutes while the guest pays, then released if payment fails
3. The Booking State Machine
Explicit states make timeouts and cancellations predictable: an expired hold always releases its nights.
4. Payments Without Double Charges
A booking touches several services: pricing, payments, payouts, ledgers. If a network call fails halfway and is retried, the guest could be charged twice.
Airbnb wrote about building Orpheus, an internal idempotency library, so payment operations can be retried safely: each request carries an idempotency key, and the result of the first successful attempt is stored and returned for retries. (See Idempotency Explained and Stripe System Design.)
5. From Monolith to Services
Airbnb began as a Ruby on Rails monolith. As engineering grew, the shared codebase slowed everyone down. Airbnb's engineers described a multi-year migration to a service-oriented architecture: data services own each domain's data, and higher-level services build features on top.
| Monolith (Monorail) | Service-oriented |
|---|---|
| One codebase, one deploy | Many services, independent deploys |
| Easy to start | Scales with team size |
| Shared database | Each domain owns its data |
| One failure can affect all | Failures more isolated |
Interview Checklist
- Geo search + filters, then ML ranking
- Availability stored per listing-night with uniqueness guarantees
- Date holds with expiry during payment
- Booking modelled as a state machine
- Idempotent payments and payouts to hosts
- Messaging, reviews and notifications driven by events
Frequently Asked Questions
How does Airbnb prevent double bookings?
A typical design stores availability per listing per night and uses database constraints, row locks or optimistic locking so only one booking can claim a night. Dates are held briefly during payment and released if payment fails or times out.
How does Airbnb search ranking work?
Airbnb has published that it moved from hand-tuned rules to machine-learning models, including gradient-boosted trees and deep neural networks, plus listing embeddings learned from browsing sessions. Models predict which listings a guest is likely to book, balanced against marketplace goals.
How would you design Airbnb in an interview?
Cover geo search with filters and ranking, an availability calendar that prevents double bookings, a booking state machine with payment holds and timeouts, idempotent payments and payouts, and event-driven notifications and reviews. Discuss caching availability for search versus exact checks at booking.
Conclusion
Airbnb's system design centres on three hard problems: ranking millions of listings for each guest, guaranteeing a night is never sold twice, and moving money exactly once. Search indexes with ML ranking, per-night availability with database guarantees, a booking state machine and idempotent payments solve them.
Sources
- Airbnb Engineering: Avoiding double payments in a distributed payments system
- Airbnb Engineering: Applying deep learning to Airbnb search (KDD 2019 paper)
- Airbnb Engineering: Listing embeddings in search ranking
- InfoQ: Airbnb's migration from monolith to SOA
Last verified: 2 November 2026.
Related reads: Stripe System Design · Distributed Locks Explained · Uber System Design · Two-Sided Marketplace Lessons
I write about system design and how real products are built. Follow on LinkedIn or X, or invite me to speak.