Design Airbnb

Question 1

Who is searching and who is booking?

Accepted Answer

The same person, doing two completely different things — a hundred searches for every booking. That ratio decides the shape of everything else.

Question 2

What do the apps connect to?

Accepted Answer

A gateway is where the browsing traffic and the booking traffic get separated, which is what lets one be cached hard and the other not at all.

Question 3

What answers "a place in Lisbon, 4 nights in June"?

Accepted Answer

Search is a read-only, latency-sensitive, heavily cached workload with a geographic and date filter. Booking is a rare transactional write. Running them in one service means scaling and failing them together.

Question 4

Two people book the last free night at the same instant. Who decides?

Accepted Answer

One place, holding one transaction. The whole correctness of this system lives in a single service making a single atomic decision, and spreading that decision across services is how double bookings happen.

Question 5

A thousand people search "Lisbon, next weekend". How many database queries?

Accepted Answer

Ideally one. Popular city-and-date searches repeat constantly and the answer barely changes minute to minute — caching them is what keeps a read-heavy product off a database that also has to serve transactions.

Question 6

Where does a confirmed booking live?

Accepted Answer

In a database that can hold a transaction and a uniqueness constraint. A booking is money and a promise — it is the one thing here that cannot be eventually consistent.

Question 7

Your client writes bookings directly. What enforces one booking per night?

Accepted Answer

The constraint may live in the database, but the decision to attempt the write, take the payment and roll back together belongs to a service.

Question 8

How many searches a second?

Accepted Answer

100,000,000 / 86,400 is about 1,160 a second, against roughly 12 bookings a second. Two orders of magnitude apart — which is why the read path gets a cache and the write path gets a transaction.

Question 9

How do you guarantee the same dates are never sold twice?

Accepted Answer

Read-then-write is a race: between checking availability and inserting the booking, somebody else inserted theirs. The fix is to make the database refuse the second write — a uniqueness constraint over the listing and date range inside one transaction — rather than to check harder in application code.

Blueprint — system design