##### Question Design an HTTP API endpoint that, given a requested date range and a collection of Airbnb listings with their availability, returns all valid **two-listing split-stay** combinations whose availability together covers the entire range with consecutive subsegments. A split stay means the guest stays at one listing for the first part of the trip and a second listing for the rest: the first listing covers nights `S..T` and the second covers `T+1..E` for some split point `T`, with at most one move. Each listing's availability is given as a set / array of day numbers (or available nights). Two listings form a valid split-stay pair if there is some split point `T` such that the first listing is available for every night in the first segment and the second is available for every night in the second segment. Address the following: 1. **API contract** — Define the request and response schemas, including how listings are identified and how availability is passed. Specify the HTTP method/path, query parameters (e.g. `start_date`/`end_date`, `min_first_nights`/`min_second_nights`, `max_results`, `sort_by`/`order_by`), and example success and error payloads. 2. **Core algorithm** — Explain how you determine, for a pair of listings, whether a feasible split exists, and how to find all such pairs efficiently. Discuss the data structures (e.g. per-listing availability bitsets, prefix/suffix coverage lengths, or maximal consecutive availability runs) that let you avoid a naive O(L²·N) scan. 3. **Multiple split points & deduplication** — A pair may admit several valid split days. Show how you represent one or more valid splits per pair, and how you deduplicate unordered pairs so `(A,B)` and `(B,A)` are emitted only once (canonical ordering). 4. **Ranking, ordering & pagination** — Describe result ordering, optional ranking (price, rating, distance, balance of the two segments), and deterministic cursor/token-based pagination with a cap on total results. 5. **Validation & edge cases** — Handle invalid inputs (bad date ranges, day numbers out of range), minimum-stay rules, time zones / DST, cleaning-day gaps between segments, and the same-listing-twice policy. 6. **System concerns at scale** — Discuss precomputation/indexing, caching, consistency/freshness model, idempotency, rate limiting, and latency/throughput targets (SLAs) for low latency on large supply. Walk through a concrete example. For listings `A:[1,2,3,6,7,10,11]`, `B:[3,4,5,6,8,9,10,13]`, `C:[7,8,9,10,11]` and date range `[3,11]` (min 1 night per segment), show that the only valid pair is `[["B","C"]]`.

This Airbnb software-engineer technical-screen system-design question asks you to design an HTTP API that returns all valid two-listing "split-stay" combinations covering a requested date range with at most one move. The solution covers the request/response contract, the feasibility test (prefix/suffix coverage bitsets or maximal availability runs), efficient candidate pairing that avoids an O(L²·N) scan, deduplication of unordered pairs, ranking and cursor pagination, and system concerns such as indexing, caching, consistency, idempotency, rate limiting, and SLAs — including a worked example that returns [["B","C"]].

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 Technical Screen 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 API for split-stay combinations | Airbnb Interview Question

Question

Design an HTTP API endpoint that, given a requested date range and a collection of Airbnb listings with their availability, returns all valid two-listing split-stay combinations whose availability together covers the entire range with consecutive subsegments. A split stay means the guest stays at one listing for the first part of the trip and a second listing for the rest: the first listing covers nights S..T and the second covers T+1..E for some split point T, with at most one move.

Each listing's availability is given as a set / array of day numbers (or available nights). Two listings form a valid split-stay pair if there is some split point T such that the first listing is available for every night in the first segment and the second is available for every night in the second segment.

Address the following:

API contract — Define the request and response schemas, including how listings are identified and how availability is passed. Specify the HTTP method/path, query parameters (e.g. start_date / end_date , min_first_nights / min_second_nights , max_results , sort_by / order_by ), and example success and error payloads.
Core algorithm — Explain how you determine, for a pair of listings, whether a feasible split exists, and how to find all such pairs efficiently. Discuss the data structures (e.g. per-listing availability bitsets, prefix/suffix coverage lengths, or maximal consecutive availability runs) that let you avoid a naive O(L²·N) scan.
Multiple split points & deduplication — A pair may admit several valid split days. Show how you represent one or more valid splits per pair, and how you deduplicate unordered pairs so (A,B) and (B,A) are emitted only once (canonical ordering).
Ranking, ordering & pagination — Describe result ordering, optional ranking (price, rating, distance, balance of the two segments), and deterministic cursor/token-based pagination with a cap on total results.
Validation & edge cases — Handle invalid inputs (bad date ranges, day numbers out of range), minimum-stay rules, time zones / DST, cleaning-day gaps between segments, and the same-listing-twice policy.
System concerns at scale — Discuss precomputation/indexing, caching, consistency/freshness model, idempotency, rate limiting, and latency/throughput targets (SLAs) for low latency on large supply.

Walk through a concrete example. For listings A:[1,2,3,6,7,10,11], B:[3,4,5,6,8,9,10,13], C:[7,8,9,10,11] and date range [3,11] (min 1 night per segment), show that the only valid pair is [["B","C"]].

Question

Address the following:

API contract — Define the request and response schemas, including how listings are identified and how availability is passed. Specify the HTTP method/path, query parameters (e.g. start_date / end_date , min_first_nights / min_second_nights , max_results , sort_by / order_by ), and example success and error payloads.
Core algorithm — Explain how you determine, for a pair of listings, whether a feasible split exists, and how to find all such pairs efficiently. Discuss the data structures (e.g. per-listing availability bitsets, prefix/suffix coverage lengths, or maximal consecutive availability runs) that let you avoid a naive O(L²·N) scan.
Multiple split points & deduplication — A pair may admit several valid split days. Show how you represent one or more valid splits per pair, and how you deduplicate unordered pairs so (A,B) and (B,A) are emitted only once (canonical ordering).
Ranking, ordering & pagination — Describe result ordering, optional ranking (price, rating, distance, balance of the two segments), and deterministic cursor/token-based pagination with a cap on total results.
Validation & edge cases — Handle invalid inputs (bad date ranges, day numbers out of range), minimum-stay rules, time zones / DST, cleaning-day gaps between segments, and the same-listing-twice policy.
System concerns at scale — Discuss precomputation/indexing, caching, consistency/freshness model, idempotency, rate limiting, and latency/throughput targets (SLAs) for low latency on large supply.

Design API for split-stay combinations

Quick Overview

Design API for split-stay combinations

Question

Submit Your Answer to Earn 20XP

Design API for split-stay combinations

Quick Overview

Design API for split-stay combinations

Question

Submit Your Answer to Earn 20XP