Nearby places — a full worked answer

Assumptions: global, hundreds of millions of places, mobile-first. Reads far outnumber writes: places change rarely and are queried constantly, an extreme ratio even for a read-heavy system. Density is very uneven: a city block can hold hundreds of places, a rural square kilometre none. Users query a small radius, typically a few kilometres.

First question, and it changes the design more than it sounds: is the ranking by distance alone, or by relevance (rating, popularity, personal history)? Distance-only can be answered entirely from a geographic index. Relevance ranking needs place attributes, and possibly per-user signals, in the ranking step, which is a second system. I will assume distance combined with quality, with no per-user personalisation, because that keeps results shareable and therefore cacheable.

Second question: does "open now" have to be exact? If a special closure must be reflected within seconds, the static-index approach needs a dynamic overlay. I will assume regular opening hours are computed at read time from static data, and irregular closures can lag by minutes.

Scope: query by location, radius and category; rank by distance and quality; filter by open now. Out of scope: navigation and routing, reviews and photos, and live availability such as table booking.

Actors: the searching user, the business owner who edits their own listing, third-party data providers, moderators, and the system, which decides which places qualify as candidates, how to rank them, when a listing is stale enough to demote, and how far to widen a search that finds nothing.

A place's life: submitted or imported → validated and deduplicated → indexed → served in results → updated periodically → possibly closed permanently.

Failure branches. At submitted: the same restaurant arrives from two data providers with slightly different names and coordinates, so without deduplication the results show it twice. This is a constant problem with place data, and it needs fuzzy matching on name and proximity. At validated: the coordinates are wrong, putting a shop in the sea, so results near that point are polluted. This needs plausibility checks against the address.

At indexed: the index build fails and new or changed places stop appearing, silently, because a slightly old index looks normal. Alert on index age, not just on job failure. At served: the area has no places within the radius. Widen it progressively rather than returning an empty list, and when there is nothing nearby, say so rather than showing something 40 km away as if it were close.

At served: the area is extremely dense, so the candidate set is thousands of places and ranking becomes expensive. Cap the candidates and shrink the search radius in dense areas: the same problem in the opposite direction, with the opposite fix.

At served: a place is permanently closed but still in the index. This is the failure users resent most: they travel somewhere that no longer exists. So closure reports need a fast path to demote or remove, faster than the normal index cycle.

And one the system owns without anyone watching: a place open 24 hours and a place that closed 10 minutes ago must be distinguishable at read time. That means evaluating the current time in the place's time zone, including daylight-saving changes and hours that run past midnight, which causes far more bugs than it sounds like it should.

Places: 200 million globally. Each is a name, coordinates, category, hours, rating and address: call it 500 bytes. That is 100 GB in total, which fits on a single machine's disk and comfortably into memory across a small cluster. The data is smaller than most people expect.

Queries: 50,000 per second at peak. Each examines candidates within a radius, and this is where density bites. In a city centre, a 2 km radius can contain 5,000 places; in a rural area, three. So the candidate set varies by three orders of magnitude for the same query, which means a fixed radius is the wrong design.

Writes: 200 million places changing perhaps once a year each is under 10 writes per second globally. That is almost nothing, and it changes my plan: this is not a write system, so I should stop thinking about write paths and spend the design effort on reads.

Cache effectiveness: queries cluster heavily in populated areas, and a query from anywhere in a city block can return the same result set. Rounding location to a grid cell makes queries from many users identical, which turns an apparently per-user query into a cacheable one. That is what makes 50,000 queries a second cheap.

So the hard part here is uneven density (the same query costs a thousand times more in a city than in the countryside), combined with making an apparently location-unique query cacheable. Not write throughput, not storage, and not the geo maths.

The geographic index: every place is assigned a geohash cell. At 6 characters a cell is about 1.2 km by 0.6 km. Places are stored keyed by cell, so finding candidates is a lookup of the user's cell plus the eight neighbours, because a place 100 metres away can be just over a boundary and missing it is a visible bug. Justified because a normal two-column index on latitude and longitude cannot answer a proximity query efficiently: it can only narrow on one column, which leaves a band around the earth.

Adaptive precision, which is the direct answer to the density number: use a longer geohash (smaller cells) in dense areas and a shorter one in sparse areas, so the candidate count stays roughly constant regardless of where the user is standing. Alternatively, start at high precision and step down until enough candidates are found. Justified explicitly by the thousand-fold variation from Stage 3.

Ranking: candidates are filtered by category and open-now, scored on distance and quality, and the top N returned. Because the index gives candidates rather than an answer, this step exists in every geospatial design and is where the product quality lives.

Open-now is computed at read time from static opening hours plus the place's time zone. This is the key decision: the index does not need to change as places open and close through the day, so a static index serves a field that appears dynamic. Irregular closures are a small overlay checked at read time. Justified by the slack analysis, which says not to make the index live.

Caching, keyed by rounded location plus radius plus category plus a coarse time bucket. Rounding the location to a grid cell is what makes distinct users share a cache entry, and the time bucket (say 15 minutes) is what lets open-now be part of a cached answer without being wrong for long. Justified by the query clustering observed in Stage 3. This box saves more work than any other in the design.

Serving: place data is small enough to hold in memory across a modest fleet, so a query is an in-memory cell lookup plus a scoring pass with no database round trip. Justified by the 100 GB figure.

Index building: a batch pipeline ingests provider feeds and owner edits, deduplicates, validates coordinates, assigns cells, and produces a new index deployed by atomic swap. Runs daily, justified by the ten-writes-per-second figure. Urgent corrections, such as a permanently closed place, go through a small overlay applied at read time, so they do not have to wait for the next build.

Partitioning: by geographic region, so a query touches only the shard covering that area, and a hot region is contained. Justified by blast radius and by the fact that queries are inherently local.

Hard part one: density, in detail. In a dense city a 2 km radius contains thousands of candidates, so scoring them all per query is the cost driver. Adaptive precision reduces the candidate set, but the better move is to precompute per cell: for each geohash cell and each category, store the top N places by quality, so a dense-area query reads a short precomputed list instead of scoring thousands. Justified by the near-zero write rate: precomputing is cheap when the data barely changes. Cost: many more index entries (one list per cell per category), and because each list is ranked within one cell, a good place just over the boundary can be missed. That is why neighbour cells still get merged in.

The boundary problem, in detail because it is the classic error in this design: a place 50 metres away but in the next cell can share only a short prefix with the user's cell, or none at all across a major boundary such as the equator or the prime meridian. So a prefix match alone misses it; querying the eight neighbours covers it. Where the search radius is larger than one cell, as in a sparse area, step down to a shorter prefix (larger cells) and widen. Cost: more cells read per query, and the candidate set grows, which is the tension adaptive precision is managing.

Hard part two: hot areas. A stadium, a festival, a transport hub at rush hour means one cell receives an enormous share of queries. Because results are cacheable and identical for everyone there, the cache absorbs most of it. That is the payoff for the Stage 1 decision to avoid personalisation. But one cache key being extremely hot makes one cache node hot, so I would replicate hot keys across several nodes with a suffix and read a random one. Cost: N times the memory for those keys and a fanned-out invalidation, both small for a handful of keys.

Pre-warming for known events is worth mentioning, because unlike most spikes these are predictable: a stadium's location and event time are both known in advance.

Deduplication, revisited as an ongoing system rather than a one-off: matching places across providers by name similarity, proximity and category, with a confidence threshold, and merging above it. Two failure directions: merging two different shops in the same building, and failing to merge one shop listed twice. The second is more visible to users, so I would tune toward merging and provide an unmerge path. Cost: some false merges, which need a correction mechanism and a human in the loop.

Consistency per feature: place data is eventually consistent by up to a day, which is fine because places rarely change. Permanent closures are near-real-time through the overlay, because showing a closed business is the most damaging error. Open-now is computed at read time, so it is correct within the cache time bucket. Ratings are eventually consistent by hours. Four features, four different freshness answers.

Multi-region: the index is small enough to replicate in full to every region, so every query is served locally with no cross-region call. Cost: full replication of 100 GB per region, which is cheap and buys local latency everywhere.

What I would monitor: query latency at p99 split by area density, since a global p99 hides the fact that city queries are the slow ones; cache hit rate; index age; the count of results returned per query, where a sudden rise in empty results is the earliest sign a build went wrong; and closure-report processing lag.