Practice/LinkedIn/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 write reviews for specific items they ordered, other users browse and interact with those reviews, and the platform awards monetary rewards based on the review's quality and impact.

The system must tie identity and eligibility to transactions, rank and surface high-signal content at scale, and handle abuse. Separate write vs. read paths, use event-driven scoring, enforce eligibility without contention, and run reliable payout workflows with auditability.

Key Requirements

Functional

Eligible review submission -- users submit reviews (rating, text, optional photos) for specific items they ordered after delivery completion
Review browsing -- users browse and search reviews on restaurant/item pages with relevance and recency sorting, pagination, and filters
Community feedback -- users mark reviews as helpful or report abuse, influencing quality scores and moderation workflows
Reward system -- users earn, view, and redeem monetary rewards based on the quality and impact of their reviews

Non-Functional

Scalability -- handle millions of reviews per day with heavy read traffic on popular restaurant pages
Reliability -- never double-pay rewards; maintain an auditable ledger of all reward transactions
Latency -- review pages load in under 300ms; review submission acknowledged within 500ms
Consistency -- strong consistency for reward payouts; eventual consistency for review rankings and aggregate scores

Interview Reports from Hello Interview

12 reports from candidates. Most recently asked at LinkedIn in Early December 2025.

Also commonly asked at: DoorDash.

What Interviewers Focus On

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

1. Eligibility Enforcement and Fraud Prevention

Allowing reviews from users who never ordered the item invites spam and reward abuse. Interviewers expect tight coupling to the order system.

Hints to consider:

Validate review eligibility by checking the orders database: the user must have a completed delivery for the specific item
Enforce per-order-item uniqueness constraints to prevent multiple reviews for the same purchase
Implement rate limiting on review submissions per user per day to prevent gaming
Flag reviews that are submitted suspiciously quickly after delivery or contain generic/duplicate text

2. Asynchronous Quality Scoring

Computing review quality synchronously on submission would couple heavy analytics to the write path. Interviewers expect a decoupled approach.

Hints to consider:

On submission, persist the review immediately and publish a review_created event to Kafka
A scoring service consumes the event, analyzes text quality (length, relevance, detail), photo quality, and assigns an initial quality score
Update the quality score over time based on helpful votes, report counts, and engagement metrics
Use the quality score to determine reward tier and ranking position, updated asynchronously

3. Reward Payout Workflow

Monetary rewards must be reliable, idempotent, and auditable. Interviewers probe the payment pipeline.

Hints to consider:

Model rewards as a ledger with immutable entries (review_id, user_id, amount, status, timestamp)
Use idempotency keys (derived from review_id + reward_tier) to prevent double-payments on retries
Implement a saga pattern: compute reward amount -> create ledger entry -> initiate payment -> update status
If payment fails, retry with exponential backoff; after max retries, move to a manual review queue

4. Read Path for Review Pages

Restaurant and item pages see heavy read traffic. Interviewers want efficient serving of sorted, paginated reviews.

Hints to consider:

Index reviews by (item_id, sort_key) in Elasticsearch for full-text search, relevance ranking, and faceted filtering
Cache the top reviews per item in Redis with short TTLs to handle traffic spikes on popular items
Precompute aggregate statistics (average rating, review count, rating distribution) and update asynchronously
Use cursor-based pagination for stable page-through even as new reviews are added

Practice/LinkedIn/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

Eligible review submission -- users submit reviews (rating, text, optional photos) for specific items they ordered after delivery completion
Review browsing -- users browse and search reviews on restaurant/item pages with relevance and recency sorting, pagination, and filters
Community feedback -- users mark reviews as helpful or report abuse, influencing quality scores and moderation workflows
Reward system -- users earn, view, and redeem monetary rewards based on the quality and impact of their reviews

Non-Functional

Scalability -- handle millions of reviews per day with heavy read traffic on popular restaurant pages
Reliability -- never double-pay rewards; maintain an auditable ledger of all reward transactions
Latency -- review pages load in under 300ms; review submission acknowledged within 500ms
Consistency -- strong consistency for reward payouts; eventual consistency for review rankings and aggregate scores

Interview Reports from Hello Interview

12 reports from candidates. Most recently asked at LinkedIn in Early December 2025.

Also commonly asked at: DoorDash.

What Interviewers Focus On

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

1. Eligibility Enforcement and Fraud Prevention

Allowing reviews from users who never ordered the item invites spam and reward abuse. Interviewers expect tight coupling to the order system.

Hints to consider:

Validate review eligibility by checking the orders database: the user must have a completed delivery for the specific item
Enforce per-order-item uniqueness constraints to prevent multiple reviews for the same purchase
Implement rate limiting on review submissions per user per day to prevent gaming
Flag reviews that are submitted suspiciously quickly after delivery or contain generic/duplicate text

2. Asynchronous Quality Scoring

Computing review quality synchronously on submission would couple heavy analytics to the write path. Interviewers expect a decoupled approach.

Hints to consider:

On submission, persist the review immediately and publish a review_created event to Kafka
A scoring service consumes the event, analyzes text quality (length, relevance, detail), photo quality, and assigns an initial quality score
Update the quality score over time based on helpful votes, report counts, and engagement metrics
Use the quality score to determine reward tier and ranking position, updated asynchronously

3. Reward Payout Workflow

Monetary rewards must be reliable, idempotent, and auditable. Interviewers probe the payment pipeline.

Hints to consider:

Model rewards as a ledger with immutable entries (review_id, user_id, amount, status, timestamp)
Use idempotency keys (derived from review_id + reward_tier) to prevent double-payments on retries
Implement a saga pattern: compute reward amount -> create ledger entry -> initiate payment -> update status
If payment fails, retry with exponential backoff; after max retries, move to a manual review queue

4. Read Path for Review Pages

Restaurant and item pages see heavy read traffic. Interviewers want efficient serving of sorted, paginated reviews.

Hints to consider:

Index reviews by (item_id, sort_key) in Elasticsearch for full-text search, relevance ranking, and faceted filtering
Cache the top reviews per item in Redis with short TTLs to handle traffic spikes on popular items
Precompute aggregate statistics (average rating, review count, rating distribution) and update asynchronously
Use cursor-based pagination for stable page-through even as new reviews are added