Katkat
Back

Design a Food Rating System

DoorDashSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This problem tests your ability to design a distributed, read-heavy rating and review system that handles high concurrency and ensures data integrity.

System Design: Food Rating Service

Design a food rating and review service for a platform like DoorDash. Users should be able to submit a rating (1-5 stars) and a written review for a specific restaurant. Other users should be able to view these ratings, see an aggregate score, and upvote/downvote reviews.

Requirements

Functional Requirements:

  1. Users can post a rating and review for a restaurant.
  2. Users can view a list of reviews for a restaurant, sorted by recent or helpfulness.
  3. Users can upvote or downvote existing reviews.
  4. The system must display an accurate aggregate rating (average star value) for each restaurant.

Non-Functional Requirements:

  1. The system is read-heavy; reviews are viewed much more frequently than they are written.
  2. High availability is critical for the review feed.
  3. The aggregate rating must be eventually consistent, but low latency for reads is prioritized.
  4. Support a scale of 100,000 requests per second across the platform.

Your Task

Provide a high-level architecture that includes:

  • API Design: Define key endpoints (e.g., POST /reviews, GET /restaurants/{id}/reviews).
  • Data Model: Schema design for storing reviews, ratings, and aggregate scores. Choose between SQL and NoSQL.
  • Storage & Caching: Describe how you handle the write load and how you ensure fast reads for the review feed.
  • Consistency: Explain how you handle the update process for aggregate ratings when a new review is added.
  • Scalability: How would you handle hot partitions (e.g., a very popular restaurant receiving thousands of reviews at once)?

Hints

Hint 1

Consider using a materialized view or a dedicated aggregation service to compute average ratings asynchronously rather than recalculating on every read.

Hint 2

For write-heavy scenarios like review submissions, consider using a message queue to decouple the request from the database update.

Hint 3

Caching strategies like Redis can store pre-computed review lists for popular restaurants to reduce database pressure.

Follow-up questions

  • How would you handle spam protection or ensure that only users who ordered from a restaurant can leave a review?
  • If we need to support 'helpful' tags, how would you design a system that prevents a single user from inflating a review's score?
  • How would you migrate the database schema if we decide to introduce multimedia attachments (photos) to reviews later?