Design a hot-listing waitlist API

Quick Overview

Design a hot-listing waitlist API evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design a hot-listing waitlist API

Company: Airbnb

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Onsite

Design a waitlist API for high-demand listings. When a user wants a date that is unavailable for a given listing, they can join a per-listing, per-date waitlist; when inventory becomes available, notify waitlisted users. Define REST/gRPC endpoints, request/response schemas, data models, and storage. Explain ordering/fairness (e.g., FIFO with priority tiers), capacity limits, deduplication, idempotency, and how users join/leave the waitlist. Describe the notification subsystem (push/email/SMS), delivery guarantees, retries, and user preferences. Address concurrency and race conditions to prevent double-booking; discuss transactions, optimistic locking, and exactly-once vs at-least-once semantics. Cover scalability for spikes, sharding strategy, backpressure, rate limiting, observability, and end-to-end testing.

Quick Answer: Design a hot-listing waitlist API evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

|Home/System Design/Airbnb
Airbnb logo
Airbnb
Jul 16, 2025, 12:00 AM
hardSoftware EngineerOnsiteSystem Design
25
0

Design a hot-listing waitlist API

System Design: Waitlist API for High-Demand Listings

Context

You are designing a waitlist system for a marketplace that offers date-based inventory (e.g., nightly stays). When a user selects a date for a given listing that is unavailable, they can join a per-listing, per-date waitlist. When inventory becomes available (e.g., due to a cancellation), the system should notify waitlisted users and prevent double-booking.

Assume:

  • Inventory is tracked per listing per date (check-in date). Some listings may have capacity >1 per date.
  • A waitlist exists per (listingId, date). Users may appear at most once per such waitlist.

Tasks

  1. Define external and internal APIs:
    • REST endpoints (paths, methods, status codes)
    • gRPC service/methods
    • Request/response schemas
  2. Propose data models and storage:
    • Entities/tables, indexes, and cache choices
    • How to store and order the waitlist (e.g., FIFO, priority tiers)
    • Capacity limits and deduplication
  3. Explain correctness and fairness:
    • Ordering policy (FIFO with optional priority tiers) and tie-breaking
    • Idempotency for join/leave and notification-triggered booking
    • How users join/leave; expiration/TTL of entries
  4. Describe the notification subsystem:
    • Push/email/SMS; user preferences (quiet hours, opt-in/out)
    • Delivery guarantees, retries, and escalation
  5. Address concurrency and race conditions:
    • Prevent double-booking when capacity reappears
    • Transactions, optimistic/pessimistic locking
    • Exactly-once vs at-least-once semantics and idempotent consumers
  6. Cover scalability and reliability:
    • Sharding/partitioning, hotspots, backpressure, rate limiting
    • Observability (metrics, logs, traces) and SLOs
  7. Propose an end-to-end testing strategy:
    • Unit, integration, property-based, load, chaos/failure injection

Include diagrams in prose if helpful and justify trade-offs.

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • API, data model, architecture, consistency, capacity, and operations.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...