Design Yelp (Nearby Business Search)

#Problem Statement

Design a service that lets users search for nearby businesses (restaurants, bars, shops) by location, category, and rating — and view detailed business pages with reviews.

📖

Real-world: Yelp is the canonical geospatial search problem, and its heart is "how do you index a map so 'find restaurants within 5km' is fast?" The classic answers — geohash (encode lat/long into a string prefix so nearby places share prefixes), quadtree (recursively subdivide dense areas), and Uber's H3 hexagons — all turn a 2D range query into something a normal index can serve, usually fronted by Elasticsearch for the text + facet + geo combination. Unlike Uber's moving points, Yelp's businesses are mostly static, so you can precompute heavily. The security/integrity story here is review fraud: fake reviews (paid 5-stars, competitor 1-star bombing) are an existential trust problem, and Yelp runs a famously aggressive review-filtering/recommendation algorithm plus sting operations against paid-review brokers — a real-world example of abuse detection as a core feature, which is the angle a security interviewer wants you to surface.

#Requirements

#Functional

• Search businesses near a location (radius or bounding box)
• Filter by category, rating, open now, price range
• Business detail page (info, hours, photos, reviews)
• User reviews and ratings
• Business owner can manage their listing

#Non-Functional

• 100M businesses, 10M DAU
• Reads >> writes (search is the primary workload)
• Search latency: < 200ms P99
• Eventual consistency acceptable (new business shows up within minutes)

#Core Design

#The Proximity Search Problem

A naïve approach: store (lat, lng) in a DB and do WHERE ST_Distance(location, ?) < radius. At 100M businesses, this is a full table scan or requires a spatial index.

Spatial Index Approaches

Geohashencode lat/lng to a base-32 string. Nearby locations share a prefix. Index on geohash → range query on prefix. Simple, but grid cells aren't perfectly uniform.

Quadtreerecursively divide the world into quadrants. Each leaf cell holds up to N businesses. Cells in dense areas (NYC) are smaller than in sparse areas (Montana). More accurate proximity but complex to maintain.

PostGIS / MySQL Spatialbuilt-in spatial index (R-tree). ST_DWithin(location, point, radius_meters) uses the index efficiently. Great for < 10M rows; needs caching at scale.

Production choicegeohash on a fast store (Redis, Elasticsearch with geo_point) is common.

-- With PostGIS
SELECT id, name, ST_Distance(location, ST_MakePoint(-122.4, 37.7)) as dist
FROM businesses
WHERE ST_DWithin(location, ST_MakePoint(-122.4, 37.7), 5000)  -- 5km radius
  AND category = 'restaurant'
ORDER BY dist
LIMIT 20;

#Architecture

Search Query → API Gateway → Search Service
                                  ↓
                          Search Index (Elasticsearch with geo_point)
                          + Business DB Cache (Redis, 1h TTL)
                                  ↓
                          Business DB (PostgreSQL + PostGIS)

Write (new/update business) → Business Service
                                  ↓
                          PostgreSQL (write)
                                  ↓
                          Sync worker → update Elasticsearch index
                                  ↓
                          Image upload → S3 + CDN

Review Service → PostgreSQL (reviews, ratings)
              → Async aggregation of avg_rating per business

#Search Index (Elasticsearch)

Elasticsearch has first-class geo support:

{
  "mappings": {
    "properties": {
      "location": { "type": "geo_point" },
      "name": { "type": "text" },
      "category": { "type": "keyword" },
      "rating": { "type": "float" }
    }
  }
}

// Query: nearby restaurants rated > 4.0
{
  "query": {
    "bool": {
      "must": [
        { "term": { "category": "restaurant" }},
        { "range": { "rating": { "gte": 4.0 }}}
      ],
      "filter": {
        "geo_distance": {
          "distance": "5km",
          "location": { "lat": 37.7, "lon": -122.4 }
        }
      }
    }
  },
  "sort": [{ "_geo_distance": { "location": { "lat": 37.7, "lon": -122.4 }, "order": "asc" }}]
}

#Reviews and Ratings

reviews(review_id, business_id, user_id, rating, text, created_at)

Average rating: computed asynchronously (updated via trigger or background job when new review is submitted). Don't compute per-request — cache avg_rating on the business row.

#Key Design Decisions

#Security Considerations

#Interview Tips