Back-of-the-Envelope Estimation

Order-of-magnitude checks catch designs that cannot work. Adjust assumptions for your interview scope — exact numbers matter less than which component becomes the bottleneck.

Assume Airbnb-scale: 150M users, 1M bookings/day, 10M active listings, avg 3 search queries per booking, 14-night avg stay window in inventory index.

Read traffic (search)

• Searches: 1M bookings × 3 ≈ 3M searches/day ≈ 35/s average.
• Peak (evening ×10) ≈ 350 search QPS to Elasticsearch — each query scans inverted index + facets, not OLTP table scan.
• Listing detail pages: ~10M views/day ≈ 115/s — cache hot listings in Redis (top 10% = 1M keys × 5 KB ≈ 5 GB).

Write traffic (booking)

• Bookings: 1M/day ≈ 11.6/s average — low QPS but strict ACID.
• Peak checkout (hourly spike ×5) ≈ 60 commits/s — each hold + confirm is a short transaction with row lock on inventory night.
• Holds: ~3× booking attempts before success → ~35 hold transactions/s peak.

Storage

• Inventory: 10M listings × 365 nights × 8 B availability bit ≈ 30 GB core calendar (simplified; real model uses date ranges).
• Bookings OLTP: 1M/day × 365 × 1 KB row ≈ 365 GB/year booking history.
• Elasticsearch index: 10M listings × 10 KB doc ≈ 100 GB (+ replicas → 300 GB).

Network & caching

• Search response ~20 KB JSON × 350 QPS ≈ 7 MB/s — modest; latency is index query time, not bandwidth.
• Redis hold TTL: 1M holds/day × 200 B ≈ 200 MB/day churn — tiny.
• Kafka booking events: 1M/day × 500 B ≈ 500 MB/day for downstream consumers.

// Airbnb-scale search vs booking
const bookingsPerDay = 1_000_000;
const searchesPerBooking = 3;
const searchQpsAvg = (bookingsPerDay * searchesPerBooking) / 86_400;
const peakSearchQps = searchQpsAvg * 10;
const peakBookingQps = (bookingsPerDay / 86_400) * 5;
console.log({ peakSearchQps: Math.round(peakSearchQps), peakBookingQps: Math.round(peakBookingQps) });