Geocoding and place search

Turning addresses and place names into coordinates and back: address parsing and normalisation, forward and reverse geocoding, gazetteers and place databases, autocomplete for places, ranking by relevance, distance and popularity, handling ambiguity and languages, and caching and freshness.

Reading is half of it. See this used in a real interview: walk through Design Google Maps →

Every map, delivery and ride app needs to understand "Starbucks near Union Square", "221B Baker St" or "the airport", and to show an address for a dropped pin. Geocoding converts text to coordinates; reverse geocoding converts coordinates to an address or place. Combined with place search and autocomplete, it is a core part of Google Maps, Yelp and Uber designs, and a good example of search with a geographic twist.

The data

• Address data: streets, house number ranges, postal codes, administrative areas (city, region, country), with geometries. Sources include government data, open data such as OpenStreetMap, and commercial providers.
• Places (points of interest): businesses and landmarks with names, categories, coordinates, hours and popularity.
• Administrative boundaries as polygons for reverse geocoding ("which city is this point in?").

Data quality varies widely by country; real systems merge sources and continuously correct from user feedback and driver or courier traces.

Forward geocoding

Turning "10 downing st london" into coordinates:

1. Normalise: case, punctuation, abbreviations ("st" to "street"), transliteration and multiple languages.
2. Parse into components (house number, street, city, postcode), using rules or statistical parsers trained on address data, since formats differ by country.
3. Match components against the address index, allowing fuzziness (typos, missing parts).
4. Interpolate the house number along the street segment if exact building points are unknown.
5. Rank candidates and return the best with a confidence and precision level (rooftop, street, city).

Reverse geocoding

Turning a coordinate into "123 Main St, Springfield":

• Find the nearest street segment and interpolate the house number, or the nearest building point, using a spatial index. See geohash vs quadtree vs H3.
• Determine city, region and country by point-in-polygon tests on boundaries, accelerated by cell coverings.
• For pickup points, prefer entrances and safe stopping spots learned from historical trips. See location tracking at scale.

Place search

Searching for "coffee" or "Blue Bottle" near the user combines text and location:

• An inverted index over names, categories and aliases, with geo fields. See how Elasticsearch works.
• Retrieval filters by distance or viewport and text match; ranking blends text relevance, distance, popularity, ratings, open-now status and personal history. See search ranking and relevance.
• Category queries ("pizza") versus named queries ("Joe's Pizza") behave differently; query understanding classifies them.

Autocomplete for places

Suggestions must appear per keystroke within tens of milliseconds:

• Prefix indexes per region, with top suggestions precomputed by popularity and boosted by proximity to the user. See tries and autocomplete.
• Mix result types: addresses, places, categories, recent searches.
• Bias toward the user's current viewport and location, but still find far-away famous places ("Eiffel Tower" from New York).

Ambiguity

"Springfield" exists in dozens of places; "Main St" in thousands of towns. Resolve with:

• The user's location and viewport.
• Popularity priors (bigger cities, more visited places).
• Asking the user to choose among top candidates when confidence is low.

Freshness and corrections

Businesses open and close, roads change. Pipelines ingest updates from data providers, business owners and user reports; edits are validated (fraud and spam are common in place data) before publishing. See trust and safety. Indexes rebuild or update incrementally; search caches have short lifetimes for place details.

Caching and serving

• Geocoding results for common queries and reverse geocoding for coarse cells are highly cacheable.
• Region-sharded indexes served from memory near users; global fallbacks for far-away queries.
• Rate limits and quotas when offering geocoding as an API. See rate limiting algorithms.

In the interview

For Design Google Maps or Design Yelp: "Queries are normalised and parsed, then matched against a region-sharded address and place index with fuzzy matching; candidates are ranked by text relevance, distance from the viewport, popularity and ratings; autocomplete serves precomputed prefix suggestions boosted by proximity; reverse geocoding uses a spatial index over street segments and boundary polygons; place data is updated through a validated edit pipeline." For Design Uber, add learned pickup points.

Checklist

• Address and place data merged from multiple sources, with boundaries.
• Normalisation and country-aware parsing; fuzzy matching; interpolation.
• Reverse geocoding with spatial indexes and point-in-polygon tests.
• Place search combining text, distance, popularity and context.
• Proximity-boosted autocomplete with mixed result types.
• Ambiguity resolved by location and popularity; validated updates; caching.