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
45 min · senior
senior

Design a system for Airbnb supporting 50M daily active users with complex search queries, real-time booking and calendar availability updates, and a scalable review system. The system must handle high concurrency, ensure data consistency for bookings, and provide low latency responses.

Constraints
  • P99 latency under 200ms for search and booking APIs
  • Strong consistency for booking and calendar availability to prevent double bookings
  • End-to-end encryption for user data and payment information
  • Offline availability of calendar data for hosts
  • Support for eventual consistency in review system with eventual reconciliation
📋
Guided Steps
1/5
Step 1
Designing the Search System
How would you design the search system to handle complex queries with filters and sorting at 50M DAU with P99 < 200ms?
💡 Hint
Consider specialized search engines optimized for full-text and faceted search with horizontal scalability.
Key Decision
Use Elasticsearch with sharding by geographic region and listing ID to support low-latency complex queries and faceted filtering.
Interviewer Expectation
Mid-level: Names Elasticsearch for search. Senior: Explains shard key choice by region to localize queries and reduce cross-shard scatter-gather, and rejects relational DB full-text search due to latency and scale.
⚠️Common Wrong Answer
Using a relational database with LIKE queries for search - leads to high latency and poor scalability at 50M DAU.
Step 2
Ensuring Consistent Booking and Calendar Availability
How do you design booking and calendar availability to prevent double bookings and ensure strong consistency?
💡 Hint
Think about distributed transactions or consensus protocols to serialize booking operations.
Key Decision
Use a distributed lock service like Apache Zookeeper or etcd to lock calendar slots during booking, combined with a strongly consistent database like CockroachDB for transactional booking writes.
Interviewer Expectation
Mid-level: Mentions locking or transactions. Senior: Explains why optimistic concurrency control alone fails under high contention and why CockroachDB's serializable isolation and distributed consensus prevent double bookings.
⚠️Common Wrong Answer
Relying on eventual consistency or last-write-wins for booking - causes double bookings and revenue loss.
Step 3
Designing Calendar Availability with Offline Support
How would you design calendar availability updates to support offline host edits and sync conflicts?
💡 Hint
Consider local caching with conflict resolution and background sync mechanisms.
Key Decision
Use a local SQLite database on host devices with CRDT-based conflict resolution and sync updates via Kafka topics to backend services for reconciliation.
Interviewer Expectation
Mid-level: Suggests caching calendar data locally. Senior: Explains CRDTs for conflict-free merges and Kafka for reliable event streaming and replay to maintain eventual consistency.
⚠️Common Wrong Answer
No offline support or naive last-write-wins sync - leads to data loss or inconsistent calendar states.
Step 4
Designing the Review System for Scalability and Consistency
How would you design the review system to handle high write volume and eventual consistency with reconciliation?
💡 Hint
Think about write-optimized NoSQL stores and asynchronous processing pipelines.
Key Decision
Use Cassandra for write-heavy review storage with partition key as listing_id, combined with Apache Kafka for streaming review events to offline analytics and reconciliation jobs.
Interviewer Expectation
Mid-level: Names Cassandra for scalability. Senior: Explains partition key choice for efficient range queries and why Kafka decouples ingestion from processing enabling eventual consistency.
⚠️Common Wrong Answer
Using relational DB with synchronous writes for reviews - causes high write latency and poor availability.
Step 5
API Design for Core User Interactions
Sketch the API design for Search, Booking, and Calendar Update endpoints focusing on request/response structure and error handling.
💡 Hint
Consider RESTful design with idempotency keys for booking and sync tokens for calendar updates.
Key Decision
Design REST APIs with JSON payloads: Search supports filters and pagination; Booking uses idempotency keys and returns booking status; Calendar Update includes sync tokens and conflict resolution metadata.
Interviewer Expectation
Mid-level: Defines basic REST endpoints. Senior: Details idempotency to prevent duplicate bookings, sync tokens for incremental calendar updates, and error codes for conflict resolution.
⚠️Common Wrong Answer
Stateless booking API without idempotency - leads to duplicate bookings on retries.
🔌
API Design Challenge
Sketch 3 core API endpoints for Airbnb: Search listings, Book a listing, and Update calendar availability.
Hints
  • How does the client send search filters and receive paginated results?
  • How does the booking API ensure atomicity and prevent double bookings?
  • How does the calendar update API handle offline host updates and sync conflicts?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use of Elasticsearch with appropriate sharding for search scalability and latency
  • Strong consistency in booking using distributed locks and transactional DB
  • Offline calendar support with conflict resolution using CRDTs and event streaming
  • Write-optimized review storage with eventual consistency via Kafka and Cassandra
Good to Have - 30%
  • API design including idempotency and sync tokens for robustness
  • End-to-end encryption for data security
  • Use of distributed consensus systems like Zookeeper or etcd for locking
Bonus - 10%
  • Detailed failure mode analysis for booking conflicts and recovery
  • Discussion of caching strategies for search and calendar data
  • Consideration of geo-distributed deployments for latency optimization
Anti-patterns to Avoid
Using relational DB full-text search causing high latency and poor scalability at 50M DAU, leading to slow responses and poor user experience
Relying on eventual consistency for booking leading to double bookings and revenue loss due to conflicting writes
No offline support for calendar causing data loss and poor host experience when network is unavailable
Synchronous review writes in relational DB causing high write latency and availability issues under heavy load
Stateless booking APIs without idempotency keys causing duplicate bookings on retries, resulting in inconsistent state and customer dissatisfaction
Polling-based calendar sync causing excessive load and poor scalability due to frequent unnecessary requests at scale
✅
Model Answer
▼ Reveal

The design uses Elasticsearch sharded by geographic region and listing ID to handle complex search queries with low latency at 50M DAU. Booking and calendar availability ensure strong consistency using distributed locking with Apache Zookeeper or etcd and transactional writes in CockroachDB. Offline calendar edits are supported via local SQLite databases on host devices with CRDT-based conflict resolution and sync through Kafka event streams. The review system is designed for high write throughput using Cassandra with listing_id partitioning and asynchronous processing via Kafka. RESTful APIs include idempotency keys for booking to prevent duplicates and sync tokens for calendar updates to handle conflicts and retries. End-to-end encryption protects user and payment data.

Key Decisions
  • Choosing Elasticsearch for search due to its full-text and faceted search capabilities and horizontal scalability
  • Sharding Elasticsearch by geographic region to localize queries and reduce cross-shard scatter-gather
  • Using distributed locks with Zookeeper or etcd to serialize booking operations and prevent double bookings
  • Employing CockroachDB for strong consistency with serializable isolation in booking transactions
  • Implementing offline calendar support with local SQLite and CRDTs to enable conflict-free merges
  • Using Kafka for reliable event streaming and asynchronous processing of calendar and review data
  • Selecting Cassandra for write-optimized, scalable review storage with partition key as listing_id
  • Designing REST APIs with idempotency keys for booking and sync tokens for calendar updates to handle retries and conflicts
  • Applying end-to-end encryption with TLS and AES-256 to secure user and payment data
  • Elasticsearch sharded by geographic region and listing ID for low-latency complex search queries
  • CockroachDB with serializable isolation for booking transactions ensuring strong consistency
  • Apache Zookeeper or etcd for distributed locking to prevent double bookings during concurrent requests
  • Local SQLite with CRDTs on host devices for offline calendar availability edits and conflict-free merges
  • Apache Kafka for reliable event streaming of calendar updates and review events enabling asynchronous processing
  • Cassandra with partition key as listing_id for write-optimized, scalable review storage
  • RESTful APIs with idempotency keys for booking and sync tokens for calendar updates to handle retries and conflicts
  • End-to-end encryption using TLS for data in transit and AES-256 for data at rest to protect user and payment data

Practice

(1/5)
1. Given a system with high read traffic and occasional cache misses causing backend overload, which cache stampede prevention strategy balances latency and backend load best?
medium
A. Use a short TTL cache with no locking, relying on backend scaling
B. Disable caching and serve all requests directly from backend
C. Use a strict distributed lock to serialize all cache regenerations
D. Implement probabilistic early expiration with randomized cache refresh triggers

Solution

  1. Step 1: Analyze trade-offs

    Short TTLs (A) cause frequent misses; strict locks (C) add latency; no cache (D) overloads backend.

  2. Step 2: Evaluate probabilistic early expiration

    Randomized early refresh spreads cache rebuilds, reducing stampede risk and latency.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Probabilistic early expiration balances load and latency effectively [check]
Hint: Randomized early refresh spreads load, avoids stampede spikes [OK]
Common Mistakes:
2. If the Market Data Feed component crashes and stops publishing updates, what is the exact failure observed by external clients subscribing to real-time stock prices?
medium
A. Clients receive stale prices indefinitely with no indication of failure
B. Clients receive partial updates but with delayed timestamps causing confusion
C. Clients receive an error message and automatic reconnection attempts begin
D. Clients continue receiving cached data from the Matching Engine without updates

Solution

  1. Step 1: Understand Market Data Feed failure impact

    When Market Data Feed crashes, it stops pushing updates; clients detect connection loss and receive error events triggering reconnection.

  2. Step 2: Eliminate other options

    Clients receive stale prices indefinitely with no indication of failure is wrong because clients detect connection loss; Clients receive partial updates but with delayed timestamps causing confusion is wrong because partial updates don't occur without feed; Clients continue receiving cached data from the Matching Engine without updates is wrong because Matching Engine doesn't serve cached market data.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Feed crash -> clients get error + reconnect attempts [check]
Hint: Feed crash triggers client error and reconnect [check]
Common Mistakes:
3. At 10x scale, which component is most likely to become the bottleneck first in the LLM-powered support bot, and why?
hard
A. The Intent Classifier service, due to synchronous LLM inference latency under high concurrency
B. The human agent pool, because fallback requests increase linearly with user queries
C. The message queue, because it cannot handle the increased throughput of fallback messages
D. The database storing user session states, due to write contention at scale

Solution

  1. Step 1: Identify scaling challenges for each component

    Human agents (A) scale linearly but can be increased with hiring. Message queue (C) scales well horizontally. Database (D) can be sharded.

  2. Step 2: Analyze Intent Classifier bottleneck

    Synchronous LLM inference is compute-intensive and latency-sensitive, causing concurrency limits and queuing delays at 10x load.

  3. Step 3: Confirm first failure point

    Intent Classifier service hits CPU/GPU resource limits first, blocking downstream components.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Synchronous LLM inference latency limits concurrency first [check]
Hint: LLM inference latency blocks concurrency at scale [check]
Common Mistakes:
4. At 10x scale, which component is most likely to fail first and why in Facebook Messenger's group chat system?
hard
A. Chat Servers because WebSocket connections are stateful and cannot be resharded easily
B. The database because it cannot handle 10x write throughput
C. Kafka brokers because partition count cannot be increased dynamically
D. Presence service because Redis TTL expiration causes message loss

Solution

  1. Step 1: Analyze stateful components at 10x scale

    Chat Servers maintain WebSocket connections bound to server memory, limiting horizontal scaling.

  2. Step 2: Compare other components

    Databases and Kafka can be sharded or scaled; Redis TTL issues cause transient problems but not first failure.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stateful WebSocket connections -> Chat Servers bottleneck at scale [check]
Hint: Stateful WebSocket binds connections -> Chat Servers bottleneck [OK]
Common Mistakes:
5. At 10x scale, which component is most likely to fail first and why in Slack's real-time delivery system?
hard
A. Chat servers, because WebSocket connections are stateful and cannot be resharded easily
B. Presence service, because TTL cache invalidations overwhelm the system
C. Kafka brokers, because partition count cannot scale beyond a fixed limit
D. The database, because increased writes cause locking and slow queries

Solution

  1. Step 1: Identify stateful bottlenecks at scale

    Chat servers hold WebSocket connections in memory, which are stateful and tied to specific servers, limiting horizontal scaling.

  2. Step 2: Compare other components

    Databases can be sharded; Kafka scales with partitions; presence service caches can be distributed; chat servers' stateful connections are the hardest to shard.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stateful WebSocket connections -> chat servers bottleneck at 10x scale [check]
Hint: Stateful WebSocket binds chat servers -> first bottleneck [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