Design a backend service that, given a caller's coordinates, returns the nearest places of interest (restaurants, ATMs, fuel stations, etc.). Think of the "what's around me" tab in a popular maps app: the caller sends a latitude/longitude and either a radius or a "give me the closest 20" request, optionally filtered by category, and gets back a distance-ranked list fast enough to feel instant.

Operating context. The catalog holds roughly 300 million places worldwide, each with coordinates, a category, a name, and a small mutable metadata blob (hours, rating, open/closed). Reads dominate massively: about 150,000 nearby-lookups/sec at steady state with peaks near 500,000/sec during lunch and evening rushes, while place data changes only ~5,000 writes/sec (new listings, edits, closures). Traffic is extremely skewed geographically — a handful of dense metros generate a large share of queries, and empty ocean or desert tiles get almost none. The read path p99 must stay under 120 ms end to end; results may be a few seconds stale.

Out of scope. Turn-by-turn routing / ETAs, the map-tile rendering pipeline, full-text place search by name, personalized ranking or ML relevance, ingestion/dedup of raw place feeds, and authentication. Assume a separate team owns each of those.

What to produce. A high-level architecture covering: the read request paths (radius query and k-nearest query), how you spatially index 300M points so a nearby lookup does not scan the world, the partitioning/sharding scheme across regions and how it copes with a few white-hot metros, the caching strategy for the read-heavy hot path, and how place edits propagate to the index and caches without stalling reads. Sketch the major components and the request flow between them; we will probe the index and hot-shard choices during checkpoints.