Design Store Locator

Problem Statement: Omnichannel Store Locator

Design an omnichannel store locator: shoppers discover brick-and-mortar stores near a geo point, see accurate hours and services, and — when a SKU is in scope — learn whether that store can fulfill a pickup today. At Walmart/Target scale this is not a static map-pin page; it is a read-heavy geospatial product fused with near-real-time inventory from store backrooms and POS feeds.

The scale and the shape

Walmart operates ~4,700 US stores, Target ~1,900, Best Buy ~1,000 — a small dataset (the entire catalog fits in RAM) serving a large read load: roughly 45M locator MAU at a p95 search under 300ms. The hard part is never the store count; it is fusing a tiny, slow-changing store catalog with a large, fast-changing inventory signal and ranking the result by proximity in milliseconds.

Why fusion is the whole problem

The failure mode that defines the product is treating the locator as a CMS-only page with no inventory truth. Show "in stock" that is not, and the shopper drives to the store, the BOPIS order cancels, and NPS craters. So the locator must answer two questions at once — which stores are near me (geo) and can this one actually fulfill (inventory) — and it must be honest about freshness when the POS feed lags. That fusion, and the honesty about its staleness, is what a Walmart/Target interviewer is actually probing.