How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Onsite rounds at Airbnb.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Airbnb during technical interviews.

Design a hot-listing waitlist API | Airbnb Interview Question

Quick Overview

This question evaluates proficiency in system design competencies such as API design (REST and gRPC), data modeling for per-listing per-date inventory, concurrency control and race-condition prevention, notification delivery, ordering and fairness policies, scalability and observability, and end-to-end testing strategies.

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

Define external and internal APIs:
- REST endpoints (paths, methods, status codes)
- gRPC service/methods
- Request/response schemas
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
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
Describe the notification subsystem:
- Push/email/SMS; user preferences (quiet hours, opt-in/out)
- Delivery guarantees, retries, and escalation
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
Cover scalability and reliability:
- Sharding/partitioning, hotspots, backpressure, rate limiting
- Observability (metrics, logs, traces) and SLOs
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.

Quick Overview

Context

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

Define external and internal APIs:

REST endpoints (paths, methods, status codes)
gRPC service/methods
Request/response schemas

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

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

Describe the notification subsystem:

Push/email/SMS; user preferences (quiet hours, opt-in/out)
Delivery guarantees, retries, and escalation

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

Cover scalability and reliability:

Sharding/partitioning, hotspots, backpressure, rate limiting
Observability (metrics, logs, traces) and SLOs

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.

Design a hot-listing waitlist API

Quick Overview

System Design: Waitlist API for High-Demand Listings

Context

Tasks

Solution

Comments (0)

Design a hot-listing waitlist API

Quick Overview

System Design: Waitlist API for High-Demand Listings

Context

Tasks

Solution

Comments (0)