Practice/DoorDash/Design a Review and Reward System for Food Delivery

Design a Review and Reward System for Food Delivery

System DesignMust

Problem Statement

Design a system that allows food delivery consumers to add reviews on ordered food items and earn monetary rewards based on the quality of their reviews. Customers who complete a delivery can write a text review and provide a star rating for specific menu items they ordered. Other users can browse, read, and interact with these reviews to help inform their purchase decisions. The platform awards monetary incentives to reviewers whose content proves valuable based on engagement signals like helpfulness votes, reading time, and community impact.

This problem combines user-generated content at scale with a financial incentive system, creating interesting challenges around fraud prevention, content quality scoring, and reliable payment processing. The system must tie review eligibility to actual purchase transactions, rank and surface high-signal content for millions of product pages, and run auditable payout workflows without double-paying or losing rewards.

Interviewers ask this to test your ability to separate write and read paths, design event-driven scoring pipelines, enforce eligibility constraints without contention, and build idempotent payment workflows. Expect questions about anti-fraud measures, content ranking algorithms, caching strategies for heterogeneous traffic patterns, and how you handle the tension between real-time responsiveness and accurate quality computation.

Key Requirements

Functional

Review submission -- Users can submit a rating and text review (with optional photos) for specific items they actually ordered, only after delivery is completed
Content discovery -- Users browse and search reviews on restaurant and item pages with relevance and recency sorting, pagination, and basic filters
Community engagement -- Users can mark reviews as helpful or report abuse, with these interactions influencing quality scores and moderation workflows
Reward distribution -- Users earn, view, and redeem monetary rewards based on the quality and impact of their reviews, processed through auditable payout workflows

Non-Functional

Scalability -- Support 100,000+ reviews submitted daily and 50 million+ review reads per day, with traffic spikes during meal ordering hours
Reliability -- Zero lost reviews or duplicate payouts; failed payout transactions must be retryable without double-crediting accounts
Latency -- Review submission acknowledged within 200 milliseconds; product page review sections load in under 300 milliseconds
Consistency -- Reviews eventually visible across all product pages; payout ledgers strongly consistent to prevent financial discrepancies

What Interviewers Focus On

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

1. Eligibility Enforcement and Fraud Prevention

Interviewers want to see how you prevent fake reviews from users who never ordered an item and how you stop reward gaming through coordinated voting or sock-puppet accounts.

Hints to consider:

Link reviews to completed order line items with a unique constraint (user_id, order_id, item_sku) to prevent duplicate submissions
Query the order service at submission time to verify purchase completion and delivery status
Implement rate limiting on review submissions and votes per user session to detect automated abuse
Use behavioral signals and device fingerprinting to flag suspicious voting patterns for manual review

2. Asynchronous Quality Scoring Pipeline

Computing quality scores involves analyzing text sentiment, image metadata, engagement metrics, and historical patterns. This must happen outside the critical write path to keep submission latency low.

Hints to consider:

Emit "review_created" events to Kafka for downstream consumers to process asynchronously
Run scoring workers that compute quality metrics (sentiment analysis, spam detection, engagement tracking) independently
Update quality scores incrementally as new signals arrive (votes, views, time-on-page) rather than recomputing from scratch
Store intermediate scoring state to support debugging and algorithm iteration

3. Read Path Optimization for Heterogeneous Traffic

Product pages must load review sections quickly despite massive read volume and highly skewed distribution where popular restaurants have thousands of reviews while long-tail items have few.

Hints to consider:

Maintain an Elasticsearch index with pre-computed aggregates (average rating, helpfulness scores) for fast ranked retrieval
Cache top-rated and most-helpful reviews per product in Redis sorted sets with TTL-based invalidation
Use cursor-based pagination to avoid offset scan penalties on large review sets
Shard review data by product ID but recognize that hot products still create read hotspots requiring caching

4. Idempotent and Auditable Reward Distribution

Financial transactions must be exactly-once from the user's perspective: no lost rewards, no double payments, and full traceability for reconciliation.

Hints to consider:

Assign each reward event a unique idempotency key derived from review ID and quality threshold milestone
Model payouts as a workflow with distinct states (pending, verified, paid, failed) persisted in an append-only ledger
Separate reward calculation from fund transfer so scoring algorithm bugs do not directly cause financial errors
Implement compensation logic to reverse incorrect payouts when quality scores are adjusted or reviews are removed

Practice/DoorDash/Design a Review and Reward System for Food Delivery

Design a Review and Reward System for Food Delivery

System DesignMust

Problem Statement

Key Requirements

Functional

Review submission -- Users can submit a rating and text review (with optional photos) for specific items they actually ordered, only after delivery is completed
Content discovery -- Users browse and search reviews on restaurant and item pages with relevance and recency sorting, pagination, and basic filters
Community engagement -- Users can mark reviews as helpful or report abuse, with these interactions influencing quality scores and moderation workflows
Reward distribution -- Users earn, view, and redeem monetary rewards based on the quality and impact of their reviews, processed through auditable payout workflows

Non-Functional

Scalability -- Support 100,000+ reviews submitted daily and 50 million+ review reads per day, with traffic spikes during meal ordering hours
Reliability -- Zero lost reviews or duplicate payouts; failed payout transactions must be retryable without double-crediting accounts
Latency -- Review submission acknowledged within 200 milliseconds; product page review sections load in under 300 milliseconds
Consistency -- Reviews eventually visible across all product pages; payout ledgers strongly consistent to prevent financial discrepancies

What Interviewers Focus On

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

1. Eligibility Enforcement and Fraud Prevention

Interviewers want to see how you prevent fake reviews from users who never ordered an item and how you stop reward gaming through coordinated voting or sock-puppet accounts.

Hints to consider:

Link reviews to completed order line items with a unique constraint (user_id, order_id, item_sku) to prevent duplicate submissions
Query the order service at submission time to verify purchase completion and delivery status
Implement rate limiting on review submissions and votes per user session to detect automated abuse
Use behavioral signals and device fingerprinting to flag suspicious voting patterns for manual review

2. Asynchronous Quality Scoring Pipeline

Hints to consider:

Emit "review_created" events to Kafka for downstream consumers to process asynchronously
Run scoring workers that compute quality metrics (sentiment analysis, spam detection, engagement tracking) independently
Update quality scores incrementally as new signals arrive (votes, views, time-on-page) rather than recomputing from scratch
Store intermediate scoring state to support debugging and algorithm iteration

3. Read Path Optimization for Heterogeneous Traffic

Product pages must load review sections quickly despite massive read volume and highly skewed distribution where popular restaurants have thousands of reviews while long-tail items have few.

Hints to consider:

Maintain an Elasticsearch index with pre-computed aggregates (average rating, helpfulness scores) for fast ranked retrieval
Cache top-rated and most-helpful reviews per product in Redis sorted sets with TTL-based invalidation
Use cursor-based pagination to avoid offset scan penalties on large review sets
Shard review data by product ID but recognize that hot products still create read hotspots requiring caching

4. Idempotent and Auditable Reward Distribution

Financial transactions must be exactly-once from the user's perspective: no lost rewards, no double payments, and full traceability for reconciliation.

Hints to consider:

Assign each reward event a unique idempotency key derived from review ID and quality threshold milestone
Model payouts as a workflow with distinct states (pending, verified, paid, failed) persisted in an append-only ledger
Separate reward calculation from fund transfer so scoring algorithm bugs do not directly cause financial errors
Implement compensation logic to reverse incorrect payouts when quality scores are adjusted or reviews are removed