Katkat
Back

Design a Food-Item Review System

DoorDashSoftware Engineer · Onsite
HardSoftware EngineerOnsiteSystem Design

Last updated

Design an item-level review and rating platform for food delivery that handles high-throughput reads, asynchronous sentiment and moderation pipelines, and near real-time score aggregations.

Scenario

In a food delivery ecosystem like DoorDash, customers leave ratings and reviews not just for the overall restaurant or delivery driver, but specifically for individual food items (e.g., "Spicy Miso Ramen", "Truffle Fries"). Item-level reviews directly influence menu discovery, personalized recommendations, and merchant feedback.

Design a scalable, highly available item-level review and rating system that supports customer submissions, media attachments (e.g., photos), automated and human moderation, and real-time aggregated metrics.

Requirements

Functional Requirements

  • Review Submission: Authenticated users who completed an order can submit a rating (1–5 stars), a text review, and optional photos for items included in their order.
  • Review Retrieval: Users browsing a restaurant menu or item detail page can view paginated reviews sorted by recency or helpfulness, along with aggregate stats (average score, star distribution breakdown, total count).
  • Review Feedback: Users can mark reviews as "helpful".
  • Moderation Pipeline: Reviews must pass through an automated moderation layer (profanity, spam, inappropriate images) before being published. Flagged reviews enter an agent moderation queue.

Non-Functional Requirements

  • Scale: 50 million Daily Active Users (DAU), 5 million completed orders per day, averaging 2 item reviews per order.
  • Read/Write Ratio: Read-heavy. Menu and item views outnumber review submissions by roughly 100:1 (around 1 billion item review queries per day).
  • Latency: P99 read latency under 50ms for aggregate stats and item review feeds; write latency under 200ms (asynchronous moderation allowed).
  • Consistency: Eventual consistency is acceptable for aggregate rating scores (within 1–2 minutes), but newly submitted reviews should be immediately visible to the submitting author.

What to Cover

  1. API Design: Define the core endpoints for submitting, reading, and voting on reviews.
  2. Data Modeling: Schema design for raw reviews, item aggregates, and helpful votes, including primary keys and indexing strategy.
  3. Aggregation Pipeline: How to maintain accurate average ratings and star breakdowns at high read volumes without scanning review tables on every read.
  4. Moderation Architecture: Workflow for processing text and images asynchronously while meeting SLA requirements.
  5. Caching & Scaling: Caching strategy for menu pages (hot items vs. long-tail items) and handling viral/promoted merchant traffic spikes.

Hints

Hint 1

Decouple review creation from public availability by assigning review statuses (e.g., pending, published, rejected) and serving unmoderated reviews only to the author.

Hint 2

Precompute review aggregations using a streaming or change-data-capture pipeline rather than executing expensive `AVG()` and `COUNT()` queries on the operational review store.

Hint 3

Counter helpful-vote write amplification and race conditions by buffering increment events in an in-memory datastore or messaging queue before batching writes to persistent storage.

Follow-up questions

  • How would you handle review aggregation when a merchant changes their recipe or item variant without changing the catalog item ID?
  • How can you detect and prevent coordinated review bombing or fake review rings targeting specific merchants?
  • If an item's rating changes significantly, how would you invalidate or update cached downstream recommendation feeds efficiently?