Design Food-Item Reviews, Ratings, and Mutable Vote Counts

Design a food-item review system for one restaurant with one menu and multiple items. Users who purchased an item may review it, and users can upvote or downvote reviews. The product displays item information, review lists, vote counts, and each item's average rating. ### Requirements and Constraints - Item pages show the item name, image, rating, and comments; frontend star rendering is outside scope. - Ratings are numeric values from 0 through 5. A review vote is separate from an item rating. - Each user has at most one review for a given item. - A user may have only one current vote on a review but may change an upvote to a downvote. - Expect about 10,000 new reviews per day. Vote and rating traffic are each discussed at roughly a million requests per day, not a million requests per second. - Review reads dominate review writes. For rating traffic, consider an approximately 50/50 read/write mix rather than classifying all rating requests as reads. - Show a small initial page of reviews and support ordering and pagination. - Reward payouts based on votes are a possible later feature; payout rules and payment execution are outside this initial release. ### Part 1 — Model Items, Reviews, Ratings, and Votes Choose the data model and write APIs, including purchase eligibility, review uniqueness, and mutable votes. #### What This Part Should Cover - Distinct item, review, purchase-eligibility, and user-to-review vote records without redundant ownership tables. - Uniqueness and concurrency rules for one review per user/item and one current vote per user/review. - Correct updates to an item's rating total and count when a rating is added or changed. ### Part 2 — Serve Lists and Counts Reliably Design the read and write paths for review pages, item averages, and upvote/downvote counts. #### What This Part Should Cover - Stable review ordering and pagination with an initial small page. - A durable source of truth for votes and ratings, plus a cache strategy that tolerates eviction. - Atomic counter changes, retries, duplicate events, and vote changes in both directions. ### Part 3 — Scale and Operate the System Explain which workloads determine capacity and how to avoid turning cached counters into a new write bottleneck. #### What This Part Should Cover - Separate review, vote, and rating rates, peak-load assumptions, and read/write mixes. - Indexed access to large vote tables and identification of hot items or reviews. - Bounded aggregation or asynchronous projections with a declared consistency trade-off and reconciliation. ```hint A changed vote affects two counters Changing an upvote to a downvote is not the same as adding a new downvote. Preserve the old per-user vote so the aggregate can apply the correct change. ``` ### What a Strong Answer Covers The data model and complete read/write paths enforce the stated uniqueness and purchase rules, keep votes separate from ratings, survive cache eviction, and scale according to measured request rates. The design explains how counts and averages recover from retries or lag and keeps undefined payout behavior out of the initial implementation. ### Follow-up Questions 1. What prevents a cached vote increment from being lost if the key is evicted before a database flush? 2. How would you update aggregates when a user changes a rating from 5 to 0? 3. Why is scanning all votes for a review on every page request undesirable even if the table has an index? 4. If a highly popular review receives many simultaneous vote changes, which write path becomes the bottleneck?