"Find ramen near me that's open now" looks like the nearby-cars query from the Uber lab. It isn't. Uber's drivers move every few seconds, so its index is rebuilt continuously from a firehose of updates. A ramen shop moves roughly never. It changes its hours a few times a year. That flips almost every trade-off: the index can be built slowly and carefully, copied many times, and cached hard.
What makes this problem hard is everything around the location. People rarely search by location alone. They search for a kind of place, with filters (open now, cheap, highly rated), ranked by a mix of how good it is and how far away it is, on a map they keep dragging around. And the same query has to work in central Mumbai, with thousands of places per square kilometre, and in a village with three.
The brief
You're building the search behind a local discovery app like Yelp or the "nearby" tab of a maps app. A user opens the app, sees good places around them, searches for something specific, drags the map to another neighbourhood and taps "search this area", then opens a place to read reviews.
Who uses it?
- People searching, mostly on phones, often standing on a street deciding where to eat in the next ten minutes.
- Business owners, who edit their listing: hours, photos, menu, "closed for renovation".
- Reviewers, who post ratings, reviews and photos.
In scope: nearby search with text and filters, ranking, map viewport search with pins and clusters, place details, and the write paths that keep listings, ratings and reviews fresh in search.
Out of scope: sponsored results and ads, typeahead suggestions (see the typeahead lab), directions and travel times (see the Google Maps lab), review moderation, and reservations.
Requirements
Functional
- Search for places near a point or inside the visible map area, by text ("ramen"), by category ("coffee"), or both.
- Filter by open now, price level, minimum rating and distance.
- Sort by best match (the default), distance or rating.
- Show results as a list and as pins on the map. When there are too many to show, group them into clusters.
- Show a place's details: hours, photos, reviews.
- Owners edit their listing. Users post reviews and photos.
Non-functional
- Fast: search responds within 200 ms at p99 on the server. People drag the map and expect results to follow.
- Highly available for reads: 99.99% for search and details. Edits and reviews can tolerate a short outage.
- Fresh enough: a listing edit (new hours, permanently closed) shows in search within 5 minutes. Ratings can lag by a few minutes more.
- Correct at the edges: a place 100 m away never goes missing because a grid line runs between it and the user.
- Scale: 200 million places worldwide, tens of thousands of searches a second at peak.
Every read requirement is strict and every write requirement relaxed. That's the shape that lets us copy and cache.