Design a Game Store with Purchases, Downloads, and Reviews

Design an application or game store with several user-facing pages. Users must be able to browse all games by category, purchase a game and download it, and add reviews. Describe the user flows, data model, APIs, and backend behavior needed to make those features work consistently. ### Constraints and Clarifying Questions - Clarify catalog size, traffic, download sizes, supported clients, and availability requirements. No numerical scale is supplied. - Establish when a purchase grants download access and what evidence confirms payment. - Clarify who may review a game, whether reviews can be edited, and whether purchases affect review eligibility. - Treat pricing, refund behavior, and download-access duration as product policies to define rather than assume. ### Part 1 — Browse the Catalog Design the category browsing and game-detail experience, including navigation between pages and the data required to render them. #### What This Part Should Cover - Games, categories, and their relationships. - Stable ordering, pagination, and appropriate catalog caching. - A clear path from the catalog to a game's details and purchase action. ### Part 2 — Purchase and Download Explain how a user buys a game, sees the purchase outcome, and downloads a game they are entitled to access. #### What This Part Should Cover - Order and payment state, including retries and uncertain outcomes. - A durable entitlement tied to confirmed purchase state. - Authorization for downloads and efficient delivery of large artifacts. ### Part 3 — Add and Display Reviews Design review creation and display. Explain the policy decisions and the consistency needed when users submit or edit reviews. #### What This Part Should Cover - Review ownership, eligibility, and storage. - Validation, repeated submissions, and basic handling of abusive content. - Pagination and any consistency trade-off between accepted reviews and cached displays. ```hint Separate the displayed result from its authority Identify which service or record authorizes a purchase, a download, and a review. A successful-looking page should not be the only evidence that the underlying action is valid. ``` ### What a Strong Answer Covers - Connected pages and APIs covering all requested features. - Consistent purchase and entitlement transitions with recoverable retries. - A review design that matches explicit policies and a download path appropriate to artifact size. ### Follow-up Questions - What happens if a user retries checkout after the payment provider completed the charge but the application timed out? - How would a refunded purchase affect download access under the chosen policy? - How do you prevent a stale page from granting access to a download or claiming a review was written by a verified purchaser?