Practice/DoorDash/Design a Review App for Food Items

Design a Review App for Food Items

System DesignMust

Problem Statement

Design a food review system where users can rate and review individual food items from their orders, other users can upvote or downvote these reviews, and reviewers receive payouts when their reviews reach certain upvote thresholds. Unlike restaurant-level review platforms, this system focuses on granular item-level feedback within a food delivery context, enabling diners to rate specific dishes like "Pad Thai from Thai Palace" rather than the restaurant as a whole.

The system blends user-generated content at scale with high-contention vote counters and a money-movement workflow. Read traffic is overwhelmingly dominant, with peak loads during lunch and dinner hours when users browse reviews before ordering. Popular reviews can attract thousands of concurrent votes, creating severe database hotspots. The payout mechanism must be fraud-resistant, accurate, and auditable since real money is changing hands based on community engagement.

Interviewers ask this because it tests your ability to separate hot paths from background processing, design idempotent write flows for both votes and payments, precompute and cache aggregates for skewed traffic patterns, and reason about consistency versus latency under real-world load. Expect deep probing on sharded counter design, eligibility enforcement, and how you prevent gaming of the reward system.

Key Requirements

Functional

Review submission -- Authenticated users who completed a purchase can post a 1-5 star rating with optional text commentary for items they actually ordered
Review discovery -- Users browse paginated lists of reviews per menu item, sorted by helpfulness, recency, or rating, with aggregate statistics visible
Helpfulness voting -- Users cast a single helpful or unhelpful vote per review, with the ability to change or retract their vote
Automated rewards -- When a review's net helpful votes exceed a configurable threshold, the author automatically receives a payment incentive

Non-Functional

Scalability -- Support 10,000 reviews submitted per minute and 100,000 votes per minute during peak meal-ordering hours
Reliability -- Zero lost reviews or votes; payout transactions must succeed exactly once per eligible review
Latency -- p99 read latency under 200 milliseconds for review lists; write acknowledgment within 500 milliseconds for votes and reviews
Consistency -- Eventual consistency acceptable for vote counts and rankings; strong consistency required for payout eligibility to prevent duplicate payments

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Purchase Verification and Review Eligibility

Interviewers want to see how you prevent fraudulent reviews from users who never ordered an item. This involves integrating order history with review permissions and handling edge cases.

Hints to consider:

Maintain a verified purchase record that links user IDs to completed order line items with delivery timestamps
Enforce a unique constraint on (user_id, order_id, item_sku) to prevent multiple reviews for the same purchase
Cache eligible items per user in Redis to avoid repeated database lookups during the submission flow
Handle edge cases like refunded orders, shared household accounts, and time windows for review eligibility

2. High-Concurrency Vote Counting Without Hotspots

A viral review might receive thousands of votes per second, creating severe contention if every vote updates a single database row. Interviewers expect a sharded counter architecture.

Hints to consider:

Distribute votes across multiple counter shards (10-100 per review), using deterministic user-ID-based hashing to assign each voter to a shard
Store individual user vote state in a separate table (user_id, review_id, vote_type) with a unique constraint for one-vote-per-user enforcement
Aggregate shard totals periodically in a background job and cache the computed sum in Redis for read operations
Use atomic conditional writes to handle vote changes (switch from helpful to unhelpful) without race conditions

3. Payout Workflow Reliability and Idempotency

Triggering payments requires coordinating vote aggregation, eligibility verification, and payment processing. Interviewers look for durable, auditable workflows.

Hints to consider:

Implement an event-driven workflow where threshold-crossing events trigger a multi-step saga or state machine
Use unique idempotency keys derived from review ID and threshold milestone to prevent duplicate payment attempts
Design a payout state table with status transitions (pending, verified, paid, failed) and an append-only audit log
Decouple the hot voting path from payout logic using Kafka to prevent payment latency from affecting vote performance

4. Review Feed Scalability and Ranking

Users expect to see the most helpful reviews quickly, but computing helpfulness scores on every page load is expensive at scale.

Hints to consider:

Precompute and materialize review rankings in background jobs triggered by vote or review events
Cache top N reviews per item per sort criterion in Redis sorted sets with TTLs based on item popularity
Use keyset pagination with indexed score or timestamp fields rather than offset-based pagination
For highly popular items, use a fan-out-on-write pattern where rankings are eagerly updated on every vote batch

Practice/DoorDash/Design a Review App for Food Items

Design a Review App for Food Items

System DesignMust

Problem Statement

Key Requirements

Functional

Review submission -- Authenticated users who completed a purchase can post a 1-5 star rating with optional text commentary for items they actually ordered
Review discovery -- Users browse paginated lists of reviews per menu item, sorted by helpfulness, recency, or rating, with aggregate statistics visible
Helpfulness voting -- Users cast a single helpful or unhelpful vote per review, with the ability to change or retract their vote
Automated rewards -- When a review's net helpful votes exceed a configurable threshold, the author automatically receives a payment incentive

Non-Functional

Scalability -- Support 10,000 reviews submitted per minute and 100,000 votes per minute during peak meal-ordering hours
Reliability -- Zero lost reviews or votes; payout transactions must succeed exactly once per eligible review
Latency -- p99 read latency under 200 milliseconds for review lists; write acknowledgment within 500 milliseconds for votes and reviews
Consistency -- Eventual consistency acceptable for vote counts and rankings; strong consistency required for payout eligibility to prevent duplicate payments

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Purchase Verification and Review Eligibility

Interviewers want to see how you prevent fraudulent reviews from users who never ordered an item. This involves integrating order history with review permissions and handling edge cases.

Hints to consider:

Maintain a verified purchase record that links user IDs to completed order line items with delivery timestamps
Enforce a unique constraint on (user_id, order_id, item_sku) to prevent multiple reviews for the same purchase
Cache eligible items per user in Redis to avoid repeated database lookups during the submission flow
Handle edge cases like refunded orders, shared household accounts, and time windows for review eligibility

2. High-Concurrency Vote Counting Without Hotspots

A viral review might receive thousands of votes per second, creating severe contention if every vote updates a single database row. Interviewers expect a sharded counter architecture.

Hints to consider:

Distribute votes across multiple counter shards (10-100 per review), using deterministic user-ID-based hashing to assign each voter to a shard
Store individual user vote state in a separate table (user_id, review_id, vote_type) with a unique constraint for one-vote-per-user enforcement
Aggregate shard totals periodically in a background job and cache the computed sum in Redis for read operations
Use atomic conditional writes to handle vote changes (switch from helpful to unhelpful) without race conditions

3. Payout Workflow Reliability and Idempotency

Triggering payments requires coordinating vote aggregation, eligibility verification, and payment processing. Interviewers look for durable, auditable workflows.

Hints to consider:

Implement an event-driven workflow where threshold-crossing events trigger a multi-step saga or state machine
Use unique idempotency keys derived from review ID and threshold milestone to prevent duplicate payment attempts
Design a payout state table with status transitions (pending, verified, paid, failed) and an append-only audit log
Decouple the hot voting path from payout logic using Kafka to prevent payment latency from affecting vote performance

4. Review Feed Scalability and Ranking

Users expect to see the most helpful reviews quickly, but computing helpfulness scores on every page load is expensive at scale.

Hints to consider:

Precompute and materialize review rankings in background jobs triggered by vote or review events
Cache top N reviews per item per sort criterion in Redis sorted sets with TTLs based on item popularity
Use keyset pagination with indexed score or timestamp fields rather than offset-based pagination
For highly popular items, use a fan-out-on-write pattern where rankings are eagerly updated on every vote batch