## Design Map-Based Home Search Design the backend for customers searching for homes on a map. A query supplies an arbitrary rectangular map region and may also filter by price range, listing status such as active or sold, square footage, bedroom count, and roughly fifty precomputed listing characteristics. Do not assume listing count, query rate, update frequency, acceptable staleness, or maximum rectangle size. Identify the values that determine the storage and indexing design. ### Part 1 — Define the Search Contract Specify the rectangle representation, boundary inclusion, filter semantics, stable listing identity, result fields, ordering, result limits, and pagination or continuation behavior. #### What This Part Should Cover - Coordinate validation, edge inclusion, and longitude-wrap semantics. - Exact conjunction and missing-field rules for optional filters. - Stable identity, deterministic ordering, and bounded responses. ```hint Define geographic edges exactly Longitude wrapping and points on a rectangle boundary can make two apparently identical implementations return different listings. ``` ### Part 2 — Model and Index Listings Design the source-of-truth listing record and a search projection. Explain how the geographic index combines with price, status, area, bedroom, and characteristic filters without creating one index for every filter combination. #### What This Part Should Cover - Authoritative listing versions and a rebuildable search projection. - Spatial candidate generation followed by exact rectangle checks. - Selective scalar or bitmap indexes chosen from query behavior. ```hint Narrow candidates in stages Use the most selective supported indexes to produce candidates, then evaluate remaining precomputed attributes without multiplying indexes combinatorially. ``` ### Part 3 — Serve Interactive Map Queries Design the read path for repeated viewport changes. Address broad rectangles, dense regions, result caps, deterministic continuation, caching, and whether results are individual homes or aggregated at low zoom. #### What This Part Should Cover - A declared cap, continuation, or aggregation policy for broad queries. - Version-bound pagination during concurrent listing updates. - Cache keys and freshness rules that include all filters. ```hint Bound every viewport response An arbitrary rectangle can cover the entire inventory, so the API needs a result policy beyond simply returning every match. ``` ### Part 4 — Apply Updates and Operate the System Handle listing creation, price or status changes, characteristic recomputation, search-index lag, deletion, duplicate events, and index rebuilds. Define freshness reporting, reconciliation, and failure metrics. #### What This Part Should Cover - Idempotent versioned upserts and tombstones. - Parallel index rebuild with validation and atomic cutover. - Lag, correctness, latency, and reconciliation observability. ```hint Keep the search projection repairable The serving index is derived state; retain versions and source offsets so it can be compared with and rebuilt from authoritative listings. ``` ### What a Strong Answer Covers - Exact rectangle and filter semantics with stable pagination. - A geographic candidate index plus selective scalar or bitmap indexes for common filters. - Bounded responses for very broad or dense viewports. - Versioned, idempotent propagation from authoritative listings to a repairable search projection. - Freshness, correctness, latency, and reconciliation observability. ### Follow-up Questions 1. How would you handle a rectangle that crosses the antimeridian? 2. How would the design change if updates must appear within one second? 3. Which filters deserve dedicated indexes, and how would production data guide that choice? 4. How would you paginate while listings are being updated?