# Design a Food Review and Voting System Design a system where users can rate a food item and write a review. Other users can upvote or downvote each review. Cover the data model, write and read APIs, vote correctness, review ranking, pagination, and the main consistency choices. The design should prevent one user from casting multiple active votes on the same review and should keep an aggregate review score consistent with vote changes. ### Constraints & Assumptions - A review belongs to one author and one food item. - A user's vote on a review is one of upvote, downvote, or no active vote. - Review text and rating edits need a defined policy rather than silently rewriting history. - Popular food items may receive concurrent reviews and votes. ### Clarifying Questions to Ask - Can one user create more than one review for the same food item? - What rating scale and moderation rules apply? - Should vote totals and food-rating aggregates be exact immediately or may reads be briefly stale? ```hint Model a vote as state, not an event count A uniqueness rule on user and review makes switching or removing a vote different from appending another upvote. ``` ```hint Choose a stable page boundary Ranking fields can change while a user paginates, so include a deterministic tie-breaker and define the consistency expected across pages. ``` ### What a Strong Answer Covers - Normalized food, review, and vote records with the necessary uniqueness constraints. - Transactional vote transitions and safe maintenance of aggregate counts. - APIs for creating, editing, listing, voting, and deleting or moderating reviews. - Stable cursor pagination and an explicit ranking formula or ordering contract. - Handling of hot reviews, abuse, authorization, and aggregate rebuilds. ### Follow-up Questions - How would you recover if a cached vote score disagrees with the vote records? - How would you rank new high-quality reviews that have few votes? - What changes if votes must be auditable as an immutable event history?