System Design HLD Example: Proximity Service (Yelp/Google Places)

Scenario context

A proximity service (Yelp/Google Places) solves the 2D search problem by encoding locations into Geohash strings, which are indexed in a standard B-tree. To guarantee results near grid boundaries, the system queries the center cell plus its 8 neighbors and then filters the results using the Haversine formula in the application layer. This architecture provides sub-100ms latency for 200M+ businesses while…

This walkthrough focuses on The Manhattan Hot-Cell Problem.

Before making a design choice, clarify:

• Imagine you’re in downtown Manhattan.
• Within a 500-meter radius of your location, there are over 2,000 restaurants, shops, and landmarks.
• You search for "Coffee," and you expect the results in milliseconds.

Concepts in play: database-indexing, sorting-and-searching-algorithms, system-design-hld-architectures, caching

Stage 1 — Proximity Service: Use Cases & Requirements

• Actors & Journeys - User: Searches for businesses by category (e.g., "Sushi") or name within a specific radius.
• They expect a list sorted by distance and rating.
• • Business Owner: Registers their business location, updates operating hours, and uploads photos.
• • Reviewer: Provides feedback and ratings, which are aggregated to influence search ranking.

Observable outcome: - Reviewer: Provides feedback and ratings, which are aggregated to influence search ranking.

Stage 2 — Basics: How Geolocation Maps to Data

• At its core, a proximity service must solve the 2D Range Search problem.
• Traditional databases are optimized for 1D searches (e.g., "find all users with age between 20 and 30").
• A B-tree index can handle this with $O(\log N)$ efficiency.
• However, geography is two-dimensional (Latitude and Longitude).

Observable outcome: However, geography is two-dimensional (Latitude and Longitude).

Stage 3 — Mechanics: Turning Coordinates into Searchable Strings

• The primary mechanism for spatial indexing is Grid Partitioning .
• We divide the world into smaller and smaller boxes.
• The Grid Approach: Divide the map into $N \times N$ squares.
• To find nearby places, you simply find which square the user is in and query all businesses with that Square ID.

Observable outcome: To find nearby places, you simply find which square the user is in and query all businesses with that Square ID.

Stage 4 — Estimations & Design Goals

• The Math of Global Proximity - Total Listings: 200 Million businesses.
• • Average Record Size: $\approx 1$ KB (ID, Name, Lat/Lon, Geohash, Category, Rating, Hours).
• • Metadata Storage: 200M $\times$ 1 KB = 200 GB .
• This fits easily on a single modern server, but for availability, we'll shard it across a cluster.

Observable outcome: This fits easily on a single modern server, but for availability, we'll shard it across a cluster.

Stage 5 — High-Level Design: The 9-Cell Expansion

• The architecture leverages Geohashing to turn 2D spatial search into a 1D range query.
• The diagram above captures the full request lifecycle.
• A user's (lat, lon) enters through the API Gateway and reaches the Search Service, which first consults the Redis Search Cache.
• On a miss it queries Postgres using the Geohash prefix index, returning a candidate set of businesses.

graph TD
    User -->|lat, lon| AG[API Gateway]
    AG -->|Search| SS[Search Service]
    SS -->|Check Cache| RC[(Redis Search Cache)]
    RC -->|Miss| DB[(Postgres: Geohash Index)]

    Owner -->|Update| BS[Business Service]
    BS -->|Write| DB
    BS -->|Invalidate| RC

    SS -->|Filter & Rank| App[App Layer]
    App --> User

Observable outcome: On a miss it queries Postgres using the Geohash prefix index, returning a candidate set of businesses.

Stage 6 — Where Proximity Search Architecture Appears in Production Systems

• The Geohash-plus-9-cell-expansion pattern is not a whiteboard exercise.
• It is the foundation of some of the most heavily used consumer apps on earth.
• Yelp serves 250 million unique monthly visitors across 200 million businesses in 32 countries.
• Their engineering blog describes a spatial indexing system where Geohash prefix queries provide the initial candidate set and a secondary ranking model — factoring in review count, price range, and personalization — re-…

Observable outcome: Their engineering blog describes a spatial indexing system where Geohash prefix queries provide the initial candidate set and a secondary ranking model — factoring in review count, price range, and personalization — re-…

End-to-end outcome

Imagine you’re in downtown Manhattan.

Alternatives considered

The source focuses on one primary design. A second architecture is not compared, so no alternative is invented here.

Failure and degraded modes

Trade-offs and Failure Modes in Geospatial Architecture

• Detection: No architecture is without compromise.
• User or operator impact: No architecture is without compromise.