Design a Food Review App: Geo Search, Ratings and Photos

Search comes first. A user should be able to find restaurants by location, cuisine, name and minimum rating, so a query like "South Indian within 3 km, 4 stars and up" works naturally. Tapping a result opens a restaurant page with its details, its current average rating, the latest reviews and a gallery of photos. This page is by far the most viewed screen, which is why it is tagged read-heavy.

On the contribution side, a signed-in diner can post a review made of a star rating from one to five and some text, and can attach food photos to it. Delivery, table reservations and payments are separate products with their own hard problems, so they are excluded to keep the discussion focused on discovery and reviews.

Search should return within about 300 milliseconds, quick enough to refresh results as filters change. Availability needs to be at least 99.9%, and the traffic pattern explains why: demand spikes around lunch and dinner, exactly when an outage would frustrate the most people.

Ratings, on the other hand, can be eventually consistent. If a fresh review takes a few seconds to move the displayed average, no one is harmed, and accepting that delay lets us update the search index asynchronously. Media storage must scale to millions of photos at low cost per gigabyte while still loading quickly on mobile networks, which points toward object storage and a CDN rather than the main database.

Assume about 1 million restaurants and around 20 million daily users who together generate roughly 100 million searches and page views a day. That averages near 1.2K requests per second, with peaks of about 5K at mealtimes. Reviews are far rarer: assume around 1 million per day, or about 12 per second.

Photos dominate storage. With roughly 500K uploads a day at about 2 MB each, the system adds close to 1 TB of images daily, which rules out keeping them in a relational database. The more important ratio is reads to writes, which is about 100 to 1. That tells us to invest in indexing and caching the read path, while writes can take a simple, transactional route.

The core entities are Restaurant, Review, Photo and User. A review belongs to one restaurant and one user, and it can reference several photos. Photos are created first and linked by ID, which keeps the review request small and lets uploads happen in parallel while the user is still typing.

GET /search accepts latitude, longitude, cuisine and a free-text query and returns a ranked list of restaurants. GET /restaurants/{id} returns the restaurant profile, its current average and an initial batch of reviews. POST /restaurants/{id}/reviews takes a rating, text and an array of photo IDs. POST /photos/upload-url returns a photo ID and a short-lived signed URL, so the image bytes go directly to storage instead of through the API tier.

Every request lands on a gateway layer, where the caller is identified and the call is forwarded to the matching service. Search queries go to a search service backed by Elasticsearch, where every restaurant is a document with its coordinates, cuisine tags and current rating. Review submissions go to a review service, which writes to Postgres and adjusts the restaurant's rating fields inside the same transaction, so the database always holds a consistent view.

Each committed review also emits a change event to Kafka. An indexer consumes those events and refreshes the corresponding Elasticsearch document a few seconds later. Images bypass the backend completely: clients upload them to S3 and everyone else downloads them through the CDN. The result is two independent paths, one tuned for queries and one for durable writes, and each can be scaled without touching the other.

Each restaurant document in Elasticsearch carries a geo_point for its location along with cuisine, price band, rating and the name as analysed text. A search first applies a geo-distance filter, for example a 5 km radius around the user, which the engine resolves quickly using its spatial index rather than checking every restaurant in the country.

User filters come next: cuisine, open now, minimum rating and price range narrow the candidate set. The survivors are then scored with a blend of distance, rating and popularity. Pure distance would always put the nearest place first; blending lets an excellent restaurant 2 km away rank above a mediocre one across the street, which is usually what diners want.

Freshness is handled by the Kafka pipeline, so new listings, menu edits and rating changes reach the index within seconds. Because most searches stay inside one city, sharding the index by city keeps queries local and balanced, and short-lived caching of popular searches, such as "pizza" in a dense neighbourhood, removes repeated work at peak hours.

Computing the average from all reviews whenever a page opens is always exact, but a popular restaurant may have thousands of reviews, and scanning them on every view wastes the database at 5K requests per second. A nightly batch job is cheap but leaves ratings up to a day old, and someone who just posted a review sees no change, which feels broken.

The chosen approach stores a running rating_sum and review_count on the restaurant row and updates both in the same transaction as the review insert. Reading the average is a single division. Edits and deletes need care: changing a review from 3 stars to 5 adds 2 to the sum, while a deletion subtracts the old rating and decrements the count.

Raw averages make poor ranking signals because a single five-star review would outrank a place with a thousand reviews averaging 4.6. Ranking therefore uses a Bayesian average, which blends each restaurant's ratings with the city-wide mean, so places with little evidence start near the average and move away only as reviews accumulate.

Uploads start with the client requesting a pre-signed URL, then sending the file directly to S3. Large images never consume app server bandwidth or memory, so the API tier stays small. When the object lands, a storage event triggers a background worker that generates resized versions and thumbnails and removes embedded GPS metadata to protect the uploader's privacy.

An automated moderation step screens each image for unsafe content. Until it passes, the photo stays in a pending state and is visible only to its author. Approved images are served via a CDN using versioned URLs, which allows very long cache lifetimes because a changed image simply gets a new address.

Most photos are viewed heavily for a short time and then rarely. Lifecycle rules move older, seldom-requested originals to cheaper storage classes, keeping the cost of that daily terabyte under control while thumbnails and recent images stay in the faster tier.

A dedicated search index gives fast, flexible geo and text queries, but it trails the database by a few seconds. Running sums make averages instant, at the cost of careful logic for edits and deletes. Direct-to-S3 uploads keep servers lean but mean validation and processing happen only after the file has arrived.

Caching restaurant pages makes the hottest screen very fast, while a new review may take a short while to appear for other viewers. Each compromise accepts a little staleness in exchange for speed, consistent with the eventual consistency the requirements already allow: query an index, maintain ratings at write time, and keep media away from the application servers.