Design Yelp: Local Business Search with Geo Queries and Reviews

Three capabilities form the core. Users search for businesses around a location, by name or by category such as pizza, and narrow results with filters like a minimum star rating. Users open a business page showing its details, photos, average rating and recent reviews. Users write a review consisting of one to five stars plus free text, and each person may review a given business only once.

Table reservations, food delivery and advertising are distinct products with their own data and workflows, so they are excluded. Leaving them out keeps the conversation on the two problems that matter here: finding nearby places quickly and keeping ratings trustworthy.

Search latency is the headline requirement: assume results must come back in under 500 ms, because people searching on a phone at a street corner abandon slow apps immediately. The workload is strongly read-dominated, with searches and page views far outnumbering new reviews, so read capacity is where most investment goes.

Availability matters most for search. If the review pipeline is slow or partly down, people should still be able to find a restaurant; the two paths must fail independently. That separation is affordable because the product tolerates eventual consistency. A review that takes a few seconds to appear in search rankings harms nobody, and accepting that lag lets the write path stay simple and decoupled from the read path.

Assume about 20 million businesses, each described by roughly 2 KB of data, for a total near 40 GB. That is small enough to hold entirely in memory across a modest cluster. Assume 50 million daily active users running about five searches each, giving around 250 million searches per day. That averages to roughly 3K searches per second, with peaks around 10K.

Writes are tiny by comparison. If the platform receives around 1 million reviews per day, that is only about 12 per second. These figures reshape the problem: storage is trivial and write throughput barely registers, so the real engineering effort belongs to answering location queries quickly and serving the hot read path efficiently.

The domain needs a business, a review, a user, and a location stored as a latitude and longitude pair. Keeping location as plain coordinates on the business record leaves us free to choose any spatial index later.

Search is GET /search with lat, lng, a text query q and a category, returning a page of businesses plus a next_cursor for pagination. Cursor-based paging avoids the cost and inconsistency of large offsets when results shift. Opening a listing calls GET /businesses/{id}, which returns details, the current rating and the newest reviews. Writing a review is POST /businesses/{id}/reviews with a stars value from 1 to 5 and the review text, returning a review_id. The user identity comes from the auth token, not the body, so nobody can post as someone else.

An API gateway sits in front of everything, handling authentication, rate limiting and routing. Search traffic goes to a search service that queries a dedicated index such as Elasticsearch, asking for places near the user's coordinates that also match the text and filters. A dedicated index is the right tool because it combines geo filtering, full-text relevance and attribute filters in a single query.

Business pages and review submissions go to a separate business service backed by Postgres, which acts as the authoritative record. Listings change rarely but are viewed constantly, so a Redis cache holds popular listings ready to serve.

The search index is kept current through change data capture: every committed change in Postgres is streamed into the index within a few seconds, without the business service having to write to two systems. Because search and reviews travel separate paths, a spike in review submissions cannot degrade search, which matches the availability goal set earlier.

The simplest attempt stores latitude and longitude as columns and filters with two ranges. A B-tree can use only one of those ranges efficiently, so the database ends up scanning a wide strip of rows and discarding most of them. At 20 million businesses that is too slow for a 500 ms budget.

A geohash avoids that problem by dividing the map into a hierarchy of grid cells, each labelled with a short string. Places in the same small cell share a longer prefix, so a proximity search turns into a prefix match that an ordinary index handles well. A quadtree is the main alternative: it subdivides only where places are dense, giving fine cells downtown and coarse ones in rural areas. It adapts nicely, but it is a custom in-memory structure that is awkward to update and replicate.

Geohash wins on simplicity, with one wrinkle. A user standing near a cell edge may be a few metres from places in the adjacent cell, so the query covers the user's cell plus the eight surrounding it, then computes exact distances to filter and rank. In practice you rarely implement this by hand; Elasticsearch geo queries, Redis GEO commands and PostGIS all provide it, and Elasticsearch adds text and filters in the same request.

Correct ratings begin with correct input. A unique constraint on the pair of user_id and business_id in the reviews table stops one person from stuffing the ballot. Next, the review insert and the rating update happen in one database transaction: the business row keeps a running sum of stars and a count of reviews, and both are changed with atomic increments. Two reviews landing at the same instant therefore cannot overwrite each other's update.

With those two stored numbers, displaying a rating is a single division rather than an aggregate over thousands of review rows. Change data capture then carries the new values into the search index, so sorting by rating reflects the review within seconds.

Raw averages still mislead. A café with a single five-star review would outrank a bistro averaging 4.6 across 2,000 reviews. A Bayesian average fixes this by blending each business's ratings with a global prior, so sparse samples are pulled toward the platform average until enough reviews accumulate to trust them.

Search scales by sharding the index geographically. Since nearly all queries are local, a typical request touches one shard, and replicas add read throughput where a city is busy. Popular searches are also cached, keyed by the geohash prefix combined with the query and filters, for example sushi with four stars or more in a given cell, using a short TTL of about a minute so results stay reasonably fresh.

Business pages live in Redis and are invalidated whenever the listing or its rating changes. Photos are stored in object storage such as S3 and delivered from a CDN near the user, keeping heavy bytes off the application servers. Finally, the system degrades gracefully: if the review path struggles, search continues serving results with ratings that may lag slightly, which is a far better outcome than an empty results page.

Choosing geohash over a quadtree buys simplicity and off-the-shelf tool support, paid for with the extra neighbour-cell lookups. Storing a running sum and count makes averages instantly available, though each review now contends on one shared row; at roughly a dozen reviews per second that contention is negligible.

Eventual consistency between Postgres and the search index keeps writes fast and the two paths independent, at the price of new reviews taking a few seconds to influence search results. Caching search responses removes a large share of index load, but a cached page can be up to a minute old. The overall recipe is short: a geo-aware index for discovery, ratings precomputed at write time, and aggressive caching wherever reads are hot.