Design Food Reviews, Votes, and Reviewer Rewards
Company: DoorDash
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
# Design Food Reviews, Votes, and Reviewer Rewards
Design a service where users can rate a food item, post a written review, and upvote or downvote another user's review. A food page displays its average rating and reviews. Review authors may receive a reward after their reviews accumulate enough qualifying upvotes.
Pay particular attention to the schema distinction between authoring a review and voting on one, enforcing at most one current vote per user per review, and ensuring the same qualifying achievement is not rewarded twice.
### Constraints & Assumptions
- A user may update their own rating or vote unless product rules say otherwise.
- A review vote is distinct from the food rating contained in a review.
- Reward thresholds and anti-abuse rules are configurable and versioned rather than assumed numerically.
- Writes may be retried, and asynchronous consumers may deliver events more than once.
- The prompt does not provide traffic or consistency targets; ask before selecting storage and aggregation strategies.
### Clarifying Questions to Ask
- Can one user post multiple reviews for the same food item?
- Does a vote update replace the previous vote, and may users vote on their own reviews?
- Must average ratings and vote counts be strongly current?
- Is a reward based on net score, total upvotes, distinct voters, or a time window?
- Can a reward be revoked after vote removal or abuse detection?
### Solving Hints
- Model each user action with its own identity and uniqueness boundary.
- Separate the source-of-truth write model from denormalized page counters.
- Make reward qualification a state transition with an auditable policy version.
### What a Strong Answer Covers
- Review, food rating, review-vote, aggregate, reward-policy, and reward-grant data models.
- Database constraints that enforce one intended rating/vote/grant despite concurrency and retries.
- Read and write APIs with authorization and idempotency behavior.
- Average-rating and vote-count maintenance, including repair or reconciliation.
- Reward issuance that is race-safe, idempotent, auditable, and resistant to obvious abuse.
- Pagination, ranking, caching, moderation, privacy, and observability.
### Follow-up Questions
1. Two votes cross the reward threshold concurrently; how is only one reward issued?
2. How would you repair a corrupted cached average rating?
3. What changes if users can have one rating but many written reviews per item?
4. How would you detect coordinated vote manipulation without blocking normal bursts?
Quick Answer: Design food ratings, written reviews, review votes, and race-safe reviewer rewards with clear schema boundaries. Enforce one current vote per user and review, maintain repairable aggregates, make writes and reward grants idempotent, version qualification policies, and address moderation and abuse.