Bird
Raised Fist0

Design Airbnb - Search, Booking, Calendar Availability, Review System

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Design Airbnb - Search, Booking, Calendar Availability, Review System
Design a scalable, low-latency Airbnb system supporting search, booking, calendar availability, and reviews at global scale
hardSearch and DiscoveryFreq: high
Prerequisites:Inverted IndexElasticsearch
⚙️
Functional Requirements
  • Full-text and faceted search for listings with filters (location, price, amenities, dates)
  • Booking system with strong consistency to prevent double bookings
  • Calendar availability management for listings with real-time updates
  • Review system allowing guests to post and read reviews with moderation
  • User profile and listing metadata management
  • Notification system for booking confirmations and reminders (optional)
📊
Non-Functional Requirements
  • Support 2 billion daily active users globally
  • Handle peak write throughput of ~925K booking/calendar updates per second
  • Search query latency under 100ms P99 globally
  • System availability of 99.99% with multi-region failover
  • Data durability with replication and backups for at least 1 year retention
❓
Clarifying Questions to Ask
  • What is the expected peak QPS for search queries and booking writes?
  • Is strong consistency required for booking and calendar availability?
  • What is the expected retention period for reviews and booking data?
  • Are listings globally distributed or regionally partitioned?
  • What is the SLA for search freshness after booking or calendar updates?
  • Should the review system support moderation and spam detection?
Out of Scope
✗ Payment processing and fraud detection
✗ User authentication and authorization
✗ Host onboarding and listing creation workflows
✗ Detailed pricing and dynamic pricing algorithms
📌
Assumptions
  • 2 billion daily active users (DAU)
  • Each user performs on average 40 actions per day (search queries, bookings, reviews)
  • Average message size (booking, calendar update, review) is 100 bytes
  • Peak write traffic is 10% of daily writes concentrated in 4 peak hours
⚡
QPS Calculation
write qps2B users × 40 actions/day ÷ 86400 sec/day ≈ 925,926 writes/sec
peak write qps925,926 × 10% × (86400 ÷ 14400) ≈ 5,555,555 writes/sec during peak 4 hours
read qpsAssuming 5 reads per write, read_qps ≈ 4,629,630 reads/sec average
💾
Storage Estimate
daily storage925,926 writes/sec × 100 bytes × 86400 sec ≈ 8 TB/day
retention days365
total storage8 TB/day × 365 days ≈ 2.9 PB raw data
with replication2.9 PB × 3 replicas ≈ 8.7 PB total storage
🖥️
Server Estimate
search nodesElasticsearch cluster with 1000 nodes to handle 4.6M QPS with 100ms P99 latency
booking serviceDistributed booking service with 500 nodes using Cassandra for writes at 5.5M writes/sec peak
🏗️
Architecture Diagram
Architecture Diagram
          +----------------+
          |   User Client  |
          +-------+--------+
                  |
                  v
          +-------+--------+
          | API Gateway    |
          +-------+--------+
          /                \
         /                  \
        v                    v
 +------+-------+    +-------+-------+
 | Search Svc   |    | Booking Svc   |
 +------+-------+    +-------+-------+
        |                    |
        v                    v
 +------+-------+    +-------+-------+
 | Elasticsearch|    | Cassandra DB  |
 +------+-------+    +-------+-------+
        |                    |
        v                    v
 +------+-------+    +-------+-------+
 | Calendar Svc |    | Review Svc    |
 +------+-------+    +-------+-------+
        |                    |
        v                    v
 +------+-------+    +-------+-------+
 | Kafka Queue  |    | Moderation Svc|
 +--------------+    +---------------+
🧩
Components
API Gateway
Entry point for all client requests, routes to appropriate microservices
Why thisNginx with Envoy proxy for global load balancing and TLS termination with low latency
Why notDirect client-to-service communication lacks centralized routing, complicates auth and throttling
Search Service
Handles listing search queries with filters and sorting
Why thisElasticsearch provides scalable inverted index, faceted search, geo queries, and near real-time indexing
Why notSolr lacks native cloud scalability and has slower indexing at 5M writes/sec scale
Booking Service
Manages booking transactions with strong consistency and concurrency control
Why thisApache Cassandra with lightweight transactions (LWT) supports linearizable writes and high write throughput
Why notRelational DBs like PostgreSQL cannot scale to 5M writes/sec and require complex sharding
Calendar Service
Maintains real-time availability calendars for listings
Why thisRedis Cluster with TTL and pub/sub for fast availability checks and cache invalidation
Why notMemcached lacks persistence and pub/sub needed for real-time calendar updates
Review Service
Stores and serves user reviews with moderation pipeline
Why thisMongoDB for flexible schema to handle varied review content and fast reads
Why notCassandra's wide-column model is less suited for complex nested review data
Kafka Queue
Asynchronous event streaming for booking, calendar updates, and review moderation
Why thisKafka supports high throughput, partitioning, and durable event storage with consumer groups
Why notRabbitMQ lacks horizontal scalability and throughput at 5M+ messages/sec
Moderation Service
Processes review content asynchronously for spam and policy violations
Why thisMicroservice consuming Kafka events with ML-based filtering and manual override workflows
Why notSynchronous moderation blocks user experience and reduces system throughput
🔄
Data Flow
1
User Client → API Gateway
User sends search or booking request
API Gateway routes based on request type
2
API Gateway → Search Service
Search queries forwarded to Elasticsearch cluster
Elasticsearch returns filtered, ranked listings within 100ms P99
3
API Gateway → Booking Service
Booking requests processed with LWT in Cassandra
Ensures no double booking with linearizable consistency
4
Booking Service → Calendar Service
Booking updates trigger calendar availability changes
Calendar service updates Redis cache and publishes events to Kafka
5
Calendar Service → Kafka Queue
Publish calendar update events
Asynchronous propagation to other services
6
Review Service → Kafka Queue
Publish new review events for moderation
Moderation service consumes and processes reviews asynchronously
7
Moderation Service → Review Service
Update review status after moderation
Approved reviews become visible to users

Practice

(1/5)
1. In the live streaming pipeline, at step 4 the Transcoder Worker reads packets from Kafka and generates HLS segments. What happens if the Transcoder Worker encounters a delayed packet for a segment already finalized?
easy
A. The Transcoder discards the packet and continues streaming
B. The Transcoder reopens the finalized segment and appends the packet
C. The Transcoder buffers the packet until the next segment window
D. The Transcoder triggers a full stream restart to maintain consistency

Solution

  1. Step 1: Understand segment finalization

    Once an HLS segment is finalized and published, it is immutable to ensure consistent playback for viewers.

  2. Step 2: Handling delayed packets

    Reopening finalized segments (B) breaks immutability. Buffering for next segment (C) misplaces packets out of order. Restarting stream (D) is costly and unnecessary. Discarding late packets (A) maintains low latency and stream integrity.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Discarding late packets preserves segment immutability and low latency [check]
Hint: Finalized HLS segments are immutable; discard late packets [check]
Common Mistakes:
2. In the vector database request flow, at Step 4 the ANN Search Worker queries the HNSW index with a new vector. What state does the worker observe if the index is currently rebuilding due to a recent bulk insert?
easy
A. The worker returns stale search results from the previous index snapshot
B. The worker blocks until the rebuild completes before returning results
C. The worker returns an empty result set indicating no neighbors found
D. The worker queries a fallback brute-force scan of all vectors

Solution

  1. Step 1: Understand HNSW index rebuild behavior

    HNSW index rebuilds asynchronously; during rebuild, queries use the last consistent snapshot.

  2. Step 2: Analyze worker behavior at Step 4

    The ANN Search Worker returns results from the previous stable index snapshot, so stale but consistent results are served.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    HNSW queries serve last snapshot during rebuild, avoiding blocking [check]
Hint: HNSW queries serve last snapshot during rebuild, no blocking [check]
Common Mistakes:
3. In a system where a Layer 7 load balancer receives an HTTP request at step 3, what happens at step 4 when it applies URL-based routing rules?
easy
A. The load balancer inspects HTTP headers and forwards to the matched backend pool
B. The load balancer forwards the raw TCP packet without modification
C. The load balancer performs DNS resolution to select backend IP
D. The load balancer encrypts the request before forwarding

Solution

  1. Step 1: Understand Layer 7 load balancer behavior at step 4

    At step 4, the Layer 7 load balancer inspects HTTP headers (like URL path) to decide routing.

  2. Step 2: Eliminate options inconsistent with Layer 7 behavior

    Forwarding raw TCP packets (A) is Layer 4 behavior; DNS resolution (C) is client-side; encryption (D) is unrelated here.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Layer 7 LB inspects HTTP headers and routes accordingly [check]
Hint: Layer 7 LB inspects HTTP headers before forwarding [OK]
Common Mistakes:
4. In a distributed tracing system, at step 4 the Trace Collector receives a span with a missing parent ID. What is the most likely state of the trace at this point?
easy
A. The trace is complete and ready for visualization
B. The span is treated as a root span, starting a new trace segment
C. The span is discarded because it cannot be linked to any trace
D. The span is buffered indefinitely until the parent span arrives

Solution

  1. Step 1: Understand how tracing handles missing parent IDs

    Spans without parent IDs are treated as root spans, starting new trace trees.

  2. Step 2: Eliminate other options

    Discarding spans loses data unnecessarily; buffering indefinitely risks memory leaks; trace completeness requires all spans, so it's not complete yet.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Missing parent ID -> new root span starts trace segment [check]
Hint: Missing parent ID means new root span [check]
Common Mistakes:
5. At 10x transaction volume, which component is most likely to become the first bottleneck in the payment system, and why?
hard
A. The client SDK, because it cannot handle increased retry logic under load
B. The Idempotency Store, because it is a centralized stateful component with limited horizontal scaling
C. The Settlement Service, due to batch processing delays and database write contention
D. The load balancer, as it cannot distribute traffic evenly at very high request rates

Solution

  1. Step 1: Identify stateful bottlenecks at scale

    The Idempotency Store holds global state and is hard to shard, limiting horizontal scaling.

  2. Step 2: Evaluate other components

    Settlement Service can be scaled with partitioned batches; client SDK is client-side and less critical; load balancer scales horizontally with modern tech.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Centralized idempotency store -> scaling bottleneck at 10x load [check]
Hint: Centralized stateful store limits scaling first [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard