Design API for split-stay combinations
Design an HTTP API for Two-Listing Split-Stay Search
Problem Description
You are tasked with designing a search service and its corresponding HTTP API for "split stays" on a platform like Airbnb. A split stay occurs when a guest's desired date range cannot be accommodated by a single listing, requiring a combination of two separate listings to cover the entire duration with exactly one move.
The service will receive a client request specifying a date range and a set of candidate listings, each with its available day numbers within that range. The goal is to identify pairs of listings that, when combined, fully cover the guest's requested stay.
Core Assumptions
- Trip Definition: A trip is defined by a
check-indate and acheck-outdate. The total number of nights (N) for the trip is calculated as(check-out - check-in)in the requested time zone. - Availability Indexing: Available day numbers are 1-based indices over the trip nights, ranging from
1toN. Nighticorresponds to the overnight period between calendar dayiand dayi+1in the chosen time zone. - Split Logic: A split at day
simplies that Listing A covers nights1through(s-1), and Listing B covers nightssthroughN. The physical move from Listing A to Listing B occurs on the morning of days. - Cleaning Day Gap: Optionally, the system must support a cleaning-day gap of up to
gnights between Listing A and Listing B.
Key Requirements
- API Specification: Define the HTTP endpoint(s), including request and response schemas, and essential query parameters (e.g.,
start_date,end_date,max_results,sort_by). - API Features: Address pagination, idempotency, and how to effectively represent multiple valid split days for a given pair of listings in the response.
- Search Logic: Describe the rules for ranking results, handling tie-breaking scenarios, and deduplicating identical or similar split-stay options.
- System Concerns: Detail strategies for caching search results and implementing rate limiting to protect the service.
- Scalability & Performance: Explain how the service will achieve low latency at scale, considering techniques such as precomputed prefix/suffix coverage or specialized interval indexes.
- Edge Case Handling: Outline how the system will manage complexities like time zones, minimum stay requirements for individual listings, the optional cleaning-day gaps, scenarios with overlapping availability, and invalid input parameters.
- Payload Examples: Provide illustrative examples of both successful and error response payloads.
AI interview prep
Core dilemma
Balancing the combinatorial explosion of potential listing pairs and split points with the need for low-latency, highly relevant search results over dynamic availability data, while also handling complex business rules like cleaning gaps and minimum stays.
3 tradeoffs and 3 stress tests locked
Interview prep
Unlock the interviewer X-Ray rubric, tradeoff matrix, stress tests, clarifying questions, and key concepts.
Design API for split-stay combinations
Design an HTTP API for Two-Listing Split-Stay Search
Problem Description
You are tasked with designing a search service and its corresponding HTTP API for "split stays" on a platform like Airbnb. A split stay occurs when a guest's desired date range cannot be accommodated by a single listing, requiring a combination of two separate listings to cover the entire duration with exactly one move.
The service will receive a client request specifying a date range and a set of candidate listings, each with its available day numbers within that range. The goal is to identify pairs of listings that, when combined, fully cover the guest's requested stay.
Core Assumptions
- Trip Definition: A trip is defined by a
check-indate and acheck-outdate. The total number of nights (N) for the trip is calculated as(check-out - check-in)in the requested time zone. - Availability Indexing: Available day numbers are 1-based indices over the trip nights, ranging from
1toN. Nighticorresponds to the overnight period between calendar dayiand dayi+1in the chosen time zone. - Split Logic: A split at day
simplies that Listing A covers nights1through(s-1), and Listing B covers nightssthroughN. The physical move from Listing A to Listing B occurs on the morning of days. - Cleaning Day Gap: Optionally, the system must support a cleaning-day gap of up to
gnights between Listing A and Listing B.
Key Requirements
- API Specification: Define the HTTP endpoint(s), including request and response schemas, and essential query parameters (e.g.,
start_date,end_date,max_results,sort_by). - API Features: Address pagination, idempotency, and how to effectively represent multiple valid split days for a given pair of listings in the response.
- Search Logic: Describe the rules for ranking results, handling tie-breaking scenarios, and deduplicating identical or similar split-stay options.
- System Concerns: Detail strategies for caching search results and implementing rate limiting to protect the service.
- Scalability & Performance: Explain how the service will achieve low latency at scale, considering techniques such as precomputed prefix/suffix coverage or specialized interval indexes.
- Edge Case Handling: Outline how the system will manage complexities like time zones, minimum stay requirements for individual listings, the optional cleaning-day gaps, scenarios with overlapping availability, and invalid input parameters.
- Payload Examples: Provide illustrative examples of both successful and error response payloads.