Design Airbnb
Airbnb is a stays marketplace that matches guests with homes offered by hosts. Guests search near a place, book nights and pay through the platform.
The ask
A host lists a home with photos, a price per night and a calendar. A guest finds the home, picks nights and books.
Homes are unique, unlike hotel rooms of one type. One listing has one calendar, and each night on it can be sold once.
Trust runs both ways. Guests trust the home is real, and hosts trust the guest will respect it.
Payment runs through the platform. The host is paid after a stay starts, which protects both sides.
Estimate the scale
The platform holds 5,000,000 listings.
Searches run at 100,000,000 a day. 100,000,000 / 86,400 = 1,157 searches per second.
Stays booked run at 1,000,000 a day. 1,000,000 / 86,400 = 12 stays booked per second.
Searches dwarf stays. 100,000,000 / 1,000,000 = 100 searches for each stay booked.
Per listing, booking is rare. 1,000,000 / 5,000,000 = 0.2 stays per listing a day.
API and data
The operations are search stays, read a listing, hold nights, confirm a booking, cancel and message a host.
A search carries a place, dates, guest count and filters such as price and rooms. Results carry photos, price for the stay and host facts.
A listing record stores the host, the place, photos, price per night, house rules and the calendar. The calendar holds one state per night.
A booking record stores guest, listing, nights, price, fees and state. States run from held to booked to cancelled or completed.
Reviews attach to a finished stay. A review can only follow a real booking.
High-level design
Search reads a search index over listings. The index holds place, price, features and open nights in a read-ready shape.
A booking service owns calendars and holds. It is the only writer for a listing calendar.
The payment system takes the guest payment and pays the host after check-in. Holds on money mirror holds on nights.
Photos live in blob storage and ride a CDN. Listing pages stay fast while photos stay rich.
Calendar changes flow to the search index through a queue. Search display can lag, and a booking check cannot.
Deep dive: searches near a place
Guests search near a place, such as a city centre, a beach or a venue. The search must find homes around that point fast.
A geospatial index organises listings by where they sit. A geohash or a quadtree narrows the map before other filters run.
Date and guest filters run next on the narrowed set. A home with booked nights leaves the results for those dates.
Results sort by a mix of fit, price and quality signals from past stays. The sort reads stored scores and never scans all listings.
Popular place and date searches are cached for a short life. New bookings refresh the cached areas they touch.
Deep dive: the host calendar
Two guests can try to book the same nights on one listing at the same moment. Both saw the nights as open.
The booking service checks the calendar and places a hold as one guarded step. One listing calendar has one writer path.
The losing guest gets a clear answer and similar homes nearby. A double booking is never created and then undone.
Hosts block nights for their own use on the same calendar. A blocked night and a booked night both refuse holds.
A hold expires when payment does not finish. The nights return to open and the search index updates.
Trust and payments
Identity checks run at signup for hosts and guests. A stay record ties real people to each booking.
Guest money is held by the platform at booking. The host payout follows check-in, so a missing home can still be refunded in full.
Settlement moves the host share to the host bank account after the stay starts. Fees are recorded as their own ledger entries.
Reviews after a stay shape future trust. Fake stays cannot create reviews, because reviews follow finished bookings only.
Failures and retries
A payment retry uses the same booking reference. The stored result returns and the calendar is never held in duplicate.
A host cancellation frees the nights and refunds the guest in full. The platform helps the guest find a new home nearby.
If the booking service fails, holds pause while search stays up with a warning. Nights are never promised blind.
Messages between guest and host are stored with the booking. A dispute can then be read in full by a support person.
Evaluation and trade-offs
A search index buys fast, map-shaped search. Its cost is lag behind the calendar, repaid by a truthful hold step.
One writer per calendar buys certainty for unique homes. A famous listing at a peak moment feels that limit first.
Money held until check-in buys guest trust. Its cost is slower host payment, which hosts accept for steady bookings.
The design keeps one promise per listing. Each night sells once, to one guest, at the shown price.
Scale at a glance
| Measure | Value |
|---|---|
| Listings | 5,000,000 |
| Searches a day | 100,000,000 |
| Searches per second | 1,157 |
| Stays booked a day | 1,000,000 |
Exercise
What stops two guests booking the same home for the same nights?