Design Yelp — System Design Interview Guide

Functional requirements

• Search businesses near a location, filtered by category, rating, price tier, and hours
• View a business detail page with reviews, photos, ratings, hours, and address
• Write a review with a star rating, text, and optional photos
• Browse reviews for a business sorted by recency, rating, or 'most helpful'
• Owner responds to reviews (claimed-business workflow)

Non-functional requirements

• Search latency: <300ms p99 for 'restaurants near me' on mobile
• Read-heavy: ~100:1 read-to-write ratio (review reads dominate review writes)
• Availability: 99.99% for search and reads; degraded review writes acceptable for short windows
• Scale: ~100M MAU, ~5M+ businesses, ~250M+ reviews, peak ~50K searches/sec

Capacity estimation

Public Yelp scale (2022-2024): ~80-100M monthly active users, ~5M+ business listings, ~250M+ cumulative reviews. Daily searches: ~50M = ~600 searches/sec average, peak ~50K searches/sec at meal-time hours. New reviews: ~50K/day = ~1 review/sec average — review writes are tiny compared to search reads.

Storage: a business is ~5 KB (name, address, hours, category, photos URLs, owner metadata). 5M businesses × 5 KB = ~25 GB primary business data. Reviews are bigger: 250M × ~1 KB text + metadata = ~250 GB. Photos are the byte volume: avg 5 photos/business and 2 photos/review = ~25M business photos + 500M review photos at avg 500 KB = ~265 TB in object storage.

The shape that matters: this is fundamentally a read-heavy + geospatial search problem. Sharding the business store by geographic region (city/metro) keeps most queries on a single shard. The review store is sharded by business_id so all reviews for one business colocate. Search is the hard problem: 'best ramen near me' combines geospatial filter, category filter, full-text relevance, and rating sort — a layered query that touches multiple indexes.

High-level design

Five core domains: business catalog, reviews, search, photos, and user/auth.

Business catalog lives in a sharded relational store, sharded by geo-region (e.g. metro area). Each business row holds canonical metadata (name, address, lat/lng, category, hours, owner_id, average_rating, review_count) — the rating and review_count are denormalized aggregates updated on every new review write.

Reviews live in a separate sharded store, sharded by business_id so all reviews for one business colocate. Each review row holds (review_id, business_id, user_id, rating, text, helpful_count, created_at, photo_refs). On every review write, a stream-processing job recomputes the business's average rating and review count and writes back to the business catalog. Helpful votes are stored as a per-review counter, updated idempotently by (user_id, review_id) primary key.

Search is the centerpiece. An inverted-index cluster ingests business records via change-data-capture and stores them with geospatial coordinates (geohash or S2 cells). A search query has three filters compounded: geo (within radius of user location), text (name + category keyword match), and structured (category, price, hours-open-now). The query planner narrows by geo first (smallest cardinality), then text-matches within that subset, then sorts by relevance score (combination of distance, rating, review_count, recency). Sub-300ms latency requires the geo + text indexes to live in the same store with combined query support.

Photos are uploaded to object storage and served via a CDN. The business and review pages reference photo URLs; the app never streams bytes through application servers. An image-processing pipeline generates multiple sizes (thumbnail, medium, hero) on upload.

User auth uses standard JWT or session tokens; the user service handles signup, login, profile, and owner-claim workflow (a business owner proves ownership and unlocks the response feature).

Deep dive — the hard problem

Two deep dives: geospatial search and the review-read fan-out problem.

Geospatial search: the standard structure is a hierarchical spatial index — geohash or S2 cells. Each business is tagged with the cells it falls into at multiple precisions. A 'within 5 km of user' query computes the set of cells covering that radius and intersects with the inverted index. Geohash works for most use cases; S2 (Google's hierarchical spherical cells) handles polar regions and date-line crossings better. Either is acceptable; name one and explain why.

The full query is harder. 'Best ramen near me, open now, 4+ stars' compounds geo + category + state + rating. The query engine should narrow by geo first because that's typically the smallest filter. Then category, then state (open-now is a runtime computation from the business's hours), then rating sort. Production search engines (inverted-index clusters) support this multi-filter pattern natively; the design conversation is about ordering filters by selectivity, not about how the inverted index itself works.

Second deep dive: review reads and the aggregation problem. A business page load fetches the top ~20 reviews sorted by 'most helpful'. This sort is a per-business operation; with up to 10K reviews per business at popular places, naïve sort-on-read is slow. The standard pattern is a precomputed sorted set per business: when a 'helpful' vote arrives, the review's position in the sorted set is updated in an in-memory ranking store. A business page load reads the top N from the sorted set in O(log N).

The denormalization of rating and review_count back to the business catalog is the other half. Computing average_rating live on every page load would be a cross-shard aggregate over thousands of reviews per business — slow. Instead, the stream processor updates the denormalized columns within ~10 seconds of every new review. The brief inconsistency is acceptable; users don't notice if the average shifts a tenth of a star after a 5-minute delay.

Third tradeoff: fake reviews and spam. A new business with 50 5-star reviews in 24 hours from new accounts is almost certainly fake. Defenses: account-age weighting, IP-address clustering detection, and a machine-learned 'review-trust' score. Reviews below a trust threshold are filtered from the visible review list but kept in the database for moderation review. Mention this fraud surface; it's a reliable interviewer probe.

Common mistakes

• Storing businesses without a geospatial index — radius queries become a full table scan
• Computing average_rating live on every business page load instead of denormalizing
• Sharding reviews by review_id instead of business_id — kills review-list locality
• Skipping the fraud/fake-review surface — interviewer always asks 'what stops me from spamming 100 5-star reviews'
• Treating search filters as parallel rather than ordered by selectivity — wastes index resources on hot queries

Likely follow-up questions

• How would your design handle a viral event where one restaurant gets 10K reviews in a day?
• What changes if you support real-time updates like 'open now' or 'wait time at this restaurant'?
• How would you implement personalized search ranking (boost businesses similar to ones the user previously rated)?
• How would you detect and remove a coordinated fake-review attack on a competitor?
• How would you support a 'best restaurants in NYC overall' query that crosses regional shards?