This question evaluates system architecture and scalability competencies, including data modeling for date-range watchlists, event-driven notification pipelines, time-zone and DST handling, consistency and concurrency semantics, idempotency, sharding/caching strategies, and privacy/analytics considerations.
Design a rental-listing watchlist and notification system. Users can express interest on a listing for a specific date range (check-in to check-out). If a reservation cancellation makes the listing available for a watcher's requested dates (per your matching policy), notify the watcher. Hosts can view how many users are watching their listing. Specify: APIs and data model (users, listings, reservations, watchlist entries with date ranges, notification preferences); date-range representation and matching semantics (inclusive/exclusive bounds, time zones, partial vs full overlap policy); ingestion of reservation updates/cancellations and the algorithm to find affected watchers at scale (e.g., per-listing calendars, interval indexes, pub/sub); notification pipeline (deduplication, rate limiting, retries, idempotency); storage, sharding, and caching strategies; consistency model between reservation store and watchlist; race handling between new bookings and notifications; privacy/abuse controls and analytics for host watch counts.
Quick Answer: This question evaluates system architecture and scalability competencies, including data modeling for date-range watchlists, event-driven notification pipelines, time-zone and DST handling, consistency and concurrency semantics, idempotency, sharding/caching strategies, and privacy/analytics considerations.
Design a Rental Listing Watchlist and Availability-Notification System
You are designing a feature for a vacation-rental marketplace (Airbnb-style). A guest can watch a listing for a specific date range (check-in to check-out). When a reservation cancellation or update makes the listing available for a watcher's requested dates — per a defined matching policy — the system notifies the watcher across their preferred channels. A host can see how many users are watching their listing, without learning who those users are.
Design this system end to end. Your answer should cover the public and internal APIs and data model (users, listings, reservations, watchlist entries with date ranges, notification preferences, host watch counts); the date-range representation and matching semantics (inclusive vs. exclusive day bounds, time zones / DST, and the full-vs-partial overlap policy); the ingestion of reservation updates and cancellations (eventing, pub/sub, idempotency) and the algorithm that finds affected watchers at scale (per-listing calendars, interval indexes); the notification pipeline (deduplication, suppression, rate limiting, retries, idempotency, multi-channel preferences); the storage, sharding, and caching strategy; the consistency model between the reservation store and the watchlist; race handling between new bookings and notifications; and privacy, abuse controls, and analytics for host watch counts.
Constraints & Assumptions
Scale:
millions of listings, tens of millions of users and active watches; reservation mutations (creates/cancels/updates) at thousands per second at peak. Most listings have zero or few watchers; a small set of hot listings may have thousands.
Trigger:
only events that
free
days (cancellations, expiries, certain updates) can produce notifications. Bookings only shrink availability.
Latency target:
affected watchers detected and notifications enqueued within seconds of a freeing event; the actual delivery is asynchronous.
Correctness bar:
a watcher must never be told a range is bookable when it is not. A rare missed notification is more tolerable than a wrong one, but events should not be systematically dropped.
Privacy:
hosts see aggregate watch counts only — never watcher identities.
Assume a standard set of delivery channels (email, push, SMS) and per-user notification preferences.
Clarifying Questions to Ask
Matching policy:
must the
entire
requested range become bookable (full containment), or do we also alert on partial overlap with the freed window?
Day semantics:
are bounds inclusive or exclusive, and at what granularity (nights vs. calendar days)? Does a check-out and a same-day check-in count as a conflict?
Time zone of record:
are watch and reservation dates interpreted in the listing's local time zone, the user's, or UTC?
Already-free ranges:
if a guest watches a range that is
already
available (and so may never be "freed" by a future cancellation), should creation fire an immediate notification?
Policy gates:
do min/max-night rules, turnover gaps, and host-blocked days affect whether a contained range is actually bookable?
Notification semantics:
at-least-once or exactly-once delivery? How long should we suppress re-notifying the same watch?
What a Strong Answer Covers
Requirements & sizing:
crisp functional/non-functional split, a back-of-the-envelope that surfaces the hot-listing skew, and the key design decisions locked in (matching policy, day semantics, consistency stance).
Date & matching semantics:
half-open intervals, an explicit conflict/containment rule, a stated time zone of record, and a coherent story on DST and policy gates (min/max nights, turnover, blackout/blocked days).
Data model & APIs:
users, listings, reservations, watchlist entries, notification preferences, and host watch-count storage; public guest/host APIs plus the internal event contract; idempotent watch creation.
Ingestion & ordering:
how reservation mutations become events without dual-write inconsistency (e.g. transactional outbox), per-listing ordering, and idempotent application of redelivered events.
The affected-watcher algorithm:
computing the freed window, an index-backed containment query whose cost scales with the listing's own watcher count, the policy filter, and an honest complexity statement.
Notification pipeline:
dedup/suppression keys, rate limiting and quiet hours, retries with backoff, a dead-letter path, multi-channel fan-out, and the just-in-time re-check that prevents false positives.
Sharding, caching & consistency:
sharding the listing-centric tables by
listing_id
, a user-centric secondary access path, a calendar cache with versioning, and a clearly justified eventual-consistency model with named race mitigations.
Privacy, abuse & analytics:
bucketed / k-anonymized host counts, watch-creation rate limits and bot defenses, and the core SLO and conversion metrics.
Follow-up Questions
How would you support a
partial-overlap
matching policy (notify when
any
part of the requested range frees) without exploding the candidate set or the notification volume?
A single hot listing frees a wide window and ten thousand watchers match at once. How do you bound the per-cancellation work and avoid a notification thundering herd — and is a short "soft hold" for the first click-through worth the fairness and complexity cost?
Walk through recovery after a multi-hour outage of the match engine: how do you backfill missed freeing events without double-notifying users?
The reservation service and the watch service are separate. Why not run a strongly-consistent distributed transaction across them on every cancellation, and what specifically does the just-in-time re-check buy you instead?