Design a Menu Item Review and Rating System for a Food-Delivery Platform

Design the **menu review** feature of a food-delivery platform. The report names the problem only as "menu review" and notes that it comes with many functional requirements. This practice version takes the common reading: customers who ordered from a restaurant can rate and review the menu items they received, and the resulting ratings and reviews are shown to other customers on that restaurant's menu. Expect the interviewer to probe data schema and API details at length, even before you reach the high-level design. In the reported round this pushed the high-level design past the 45-minute mark, so plan your time to cover the requirements, the schema and APIs, the high-level design and at least one deep dive. ### Clarifying Questions - Does "menu review" mean customer reviews of menu items, as assumed here, or an internal workflow in which menu changes submitted by restaurants are reviewed before they are published? - Who may write a review: only a customer whose delivered order contained the item, and within what time after delivery? - Is a review attached to one menu item, to the whole order, or to both, and what does it contain (star rating, text, photos)? - Can reviews be edited or deleted, and can restaurants reply? - How should reviews be ordered on an item's page: most recent, most helpful, or ranked? - What happens to reviews when a restaurant renames or removes a menu item? ### Part 1 — Requirements and scope List the functional requirements, then choose which ones you will design in depth. State the non-functional requirements and a rough scale estimate. ```hint Prioritize out loud The functional list for this problem is long. Split it into must-have and later, and say which items you are deferring so the interviewer can redirect you early. ``` #### What This Part Should Cover - The core flows: submitting a review, showing item ratings on the menu, and listing the reviews of an item. - Eligibility and abuse constraints tied to real orders. - The read-heavy traffic shape, the freshness expected of displayed ratings, and a back-of-envelope estimate. ### Part 2 — Data schema and APIs Define the tables and the APIs in enough detail that someone could implement them: keys, constraints, indexes, pagination, and how the rating shown on the menu is stored and updated. ```hint Separate raw reviews from what the menu shows A menu page needs one number per item on every view, while an item's review list needs paginated raw rows. Consider whether those two reads should be served from the same data. ``` #### Clarifying Questions for this Part - Must a new review change the rating shown on the menu immediately, or is a delay of seconds to minutes acceptable? - May one customer review the same item again after ordering it in a later order? #### What This Part Should Cover - A review schema whose keys enforce eligibility and prevent duplicates. - A precomputed per-item aggregate and how it stays correct through edits, deletions and moderation. - Write, read and list APIs with pagination and idempotency. ### Part 3 — High-level design and deep dive Present the architecture for the write and read paths, then go deep on one area of your choice. ```hint Pick a deep dive with a real trade-off Good candidates are areas where two reasonable designs differ in consistency, cost or latency, such as keeping aggregates correct, moderating content before display, or serving ratings at menu-view volume. ``` #### What This Part Should Cover - Services, storage and asynchronous components, with the path of one review from submission to display. - Caching of menu ratings and how the cache stays current. - One deep dive with alternatives weighed and a failure mode handled. ### What a Strong Answer Covers - Time management that reaches an end-to-end design while still answering schema and API questions precisely when asked. - Order-based eligibility and duplicate prevention built into the data model rather than checked only in application code. - A deliberate consistency choice for aggregates, with the reason the product can tolerate it. - Awareness of abuse, moderation and item lifecycle (renamed, removed or changed items). ### Follow-up Questions - How would you rank reviews on an item page so that recent and helpful reviews surface without burying older critical ones? - How would you recompute aggregates after a bug corrupted them, without taking ratings off the menu? - How would you detect and handle coordinated fake reviews? - If item ratings should influence search and recommendation ranking, how would you publish rating changes to those systems?