Design a Food Item Review and Customer Reward System for a Delivery App

Design a system for a food delivery app in which customers review the food items they ordered and are rewarded for doing so. This is the system design half of a long onsite round for a product-focused software engineering role, so expect the interviewer to weigh product judgment as heavily as architecture. When you ask clarifying questions, the interviewer may hand some of them back for you to decide and justify, and partway through your deep dives they may stop you to drill into how the reward mechanism itself should work. The interviewer has said there is no single right answer for the reward design; they want to see how you reason toward something practical. The report gives no scale or feature details, so work from this standard scope and state anything else as an assumption: - A customer can review items from orders delivered to them, with a rating and optional text. - Item and restaurant pages show an aggregate rating and recent reviews. - Customers earn some kind of reward for reviewing; what kind, and under what rules, is part of the problem. - Scale numbers are yours to estimate and state. ### Clarifying Questions - Are reviews written per food item, per restaurant, or both, and can a customer edit or delete a review later? - Who may review: only a customer whose delivered order contained the item, and for how long after delivery? - What form does the reward take (points, account credit, discounts, status), and should it depend on the quality of the review? - Should a review appear immediately, or only after it passes moderation? - Do restaurants see reviews, and can they respond? ### Part 1 — Scope it with product decisions Ask your clarifying questions. For those the interviewer hands back, make a decision and justify it from the point of view of the customer, the restaurant and the business. Then state the functional and non-functional requirements and the rough scale you will design for. ```hint Decide like an owner For each open question, say who benefits from each option and what could go wrong if you choose it, then commit to one. ``` #### What This Part Should Cover - Clarifying questions that change the design, not only the numbers - Decisions with a stated justification when a question comes back to you - Functional and non-functional requirements, including what is out of scope - Rough estimates for review writes and rating reads ### Part 2 — High-level design and core flows Design the review side: the data model, the APIs, the write path for submitting a review, the read path for item pages with aggregate ratings, and how reviews are checked before or after they are shown. ```hint Reads dwarf writes Consider how an item page can show an average over thousands of reviews without reading them on every view. ``` #### What This Part Should Cover - Entities and keys linking reviews to customers, orders and items - A write path with eligibility checks and protection against duplicate submissions - Precomputed aggregates and a cached read path - Moderation and how it interacts with publishing ### Part 3 — Design the reward mechanism The interviewer cuts the remaining deep dives short and asks how you would actually devise the reward system. Propose what earns a reward, how much and when it is granted; how you keep rewards from distorting or polluting the reviews; and how you would tell whether the program works. Then show how rewards are recorded and granted reliably. ```hint Reward what you want more of Ask what kind of review is genuinely useful to the next customer, and how someone could game a naive rule to collect rewards without producing it. ``` #### What This Part Should Cover - A practical, explainable earning rule with eligibility and limits - Abuse and rating-bias risks with concrete mitigations - Success metrics and a way to validate the program - A reliable grant flow that never credits the same review twice ### What a Strong Answer Covers - Product questions asked before architecture, with decisions owned and justified - A clean review pipeline with verified-purchase writes and fast reads - A reward program that is practical, honest and measurable - Correct handling of rewards when reviews are edited, deleted or removed - Reasoning spoken aloud, with trade-offs named rather than a claim of one perfect design ### Follow-up Questions - A review that earned a reward is later removed by moderation. What happens to the reward? - How do you stop a restaurant from boosting its own ratings through fake or friendly accounts? - A restaurant changes its kitchen and its food improves. Should old reviews still count the same as new ones? - How would you find out whether rewards improve review quality or only review volume?