Airbnb

Three conceptual tiers: the search tier (read-heavy, eventually consistent), the booking tier (write-heavy, strongly consistent), and pricing / ML (mostly offline feature stores + real-time serving). Search and booking both touch the calendar, but for different purposes — search reads a pre-joined, denormalized view; booking takes a short-lived lock on the authoritative row.

Two things are unusual about Airbnb search. First, the filter is a date range, not a single date — you need listings where every night in [checkin, checkout) is available. Second, pricing is per-night and dynamic — the "total price" shown in search results has to be computed per (listing, date-range). Both are hard to do at 50K QPS.

Indexing strategy. The search index stores, for each listing, a compact availability bitmap (one bit per night for the next ~365 days — 46 bytes) plus geo (H3 cells), amenities (tokenized), and a pre-computed nightly price per day. A search query:

1. Geo-filter to listings in the bounding box.
2. AND the bitmap against the requested date range — listings with any zero bit in range are excluded. (Elasticsearch handles this natively via bitmap intersection.)
3. Price filter: compute total (sum of nightly prices for range + fees) and filter to ≤ price_max.
4. Rank by personalized relevance (learning-to-rank model; features include match score, reviews, host response rate, booking probability).

Critically, the search index is eventually consistent. Host edits and bookings emit events on Kafka; an indexer consumer updates Elasticsearch with a few-second lag. That lag is acceptable because the booking-time re-check is strongly consistent (see saga below).

Booking saga. A booking is not a single DB write; it's a sequence of operations across multiple services, each of which can fail. If any step fails, prior steps must be compensated.

1. Quote lock (optional). Guest hit quote endpoint earlier; we have a quote_id reserving a price for 10 minutes.
2. Availability lock. Take an advisory lock on the (listing_id, date_range) rows in Postgres calendar. Use SELECT … FOR UPDATE to prevent concurrent bookings.
3. Re-verify availability + price. The eventual-consistency search might have been wrong; check authoritatively. If unavailable or price changed materially, abort.
4. Authorize payment. Call Stripe with idempotency key = reservation attempt id.
5. Commit reservation. Write reservation row + flip calendar bits to booked. Atomic via DB transaction.
6. Release advisory lock. Emit ReservationCreated event to Kafka.
7. Downstream, async: host notification, calendar sync to iCal/Google Cal, search re-index, ML features updated.

If payment fails between steps 4 and 5: release lock, void auth, surface error. If step 5 commit fails but payment succeeded: capture is safe because idempotency key lets us retry; worst case, manual reconciliation flags a held auth that never committed.

Why not optimistic concurrency? Could work — read-version, write-check-version. Pessimistic FOR UPDATE is chosen because contention on the same (listing, dates) is rare at the individual row level (each listing has few concurrent attempts) and optimistic retries on conflict would surface "someone beat you" errors to users more often. Pessimistic locks held for <2 s are cheaper than the UX cost of aborted optimistic writes.

• Eventually-consistent search, strongly-consistent booking. This is the key architectural choice. Search is read-heavy, latency-critical, and can tolerate a few seconds of staleness because the booking path re-checks authoritatively. Trying to make search strongly consistent would cost orders of magnitude more.
• Pessimistic vs optimistic calendar locks. Pessimistic for the booking path because contention is rare + concentrated; optimistic with retry for calendar-view reads. Don't generalize one to the other.
• Pre-computed nightly prices vs compute-on-query. Pre-compute for search (needs to scale to 50k QPS; ML-driven pricing can't run per query). Recompute authoritatively at quote time (by then it's a single listing, single computation).
• Photo storage: direct-to-S3. Hosts upload directly to S3 via pre-signed URLs. App servers never handle the bytes. Derivatives (different sizes) generated async.
• Reviews are blind until both sides submit (or 14 days pass). A product-design choice that becomes a data-model choice: review goes into a "pending" state until the reveal trigger. Simpler than it sounds but often missed in interviews.

1. Lead with the consistency split. "Search is eventually consistent; booking is strongly consistent; the booking saga re-verifies authoritatively." This sentence shows you've thought about the hard part.
2. Date-range availability bitmaps. Mention them by name. Most candidates don't know this representation; it's specific and correct.
3. Price quote locking. 10-minute quote window. Prevents "I see $200, I go enter my card, I see $230." A small detail that shows care for UX.
4. Saga, not 2PC. Airbnb is a canonical saga example. Don't propose distributed transactions across payment + calendar.
5. Reviews and trust. Often skipped. The blind-review system is a product-design decision with a data-model implication — worth mentioning.