Design a Digital Game Store and Distribution Platform Like Steam

Design a digital game distribution platform like Steam. Players use a desktop client to browse a store, buy games, see the games they own in a library, and download, install and update those games. Developers publish games and release new builds. The interview reported only the prompt "design Steam", so the scope below is the standard implied scope. Confirm it through the clarifying questions. Assume the core flows are: - **Store**: browse and search the catalog, and view game pages with prices for the player's region. - **Purchase**: buy a game; once the payment succeeds, the game appears in the player's library. - **Library and launch**: list owned games; ownership is checked before a game launches. - **Download and update**: install an owned game, and receive updates when the developer ships a new build. - **Publishing**: a developer uploads a new build and releases it to players. ```hint Where the bytes go Game builds are large binaries, and a popular release or patch is downloaded by a huge number of players at nearly the same moment. Think about which part of the system actually serves those bytes, and how an update avoids re-sending data a player already has. ``` ```hint Ownership is the contract After a purchase, one record decides whether a player may download and launch a game. Consider what happens if the payment succeeds but that record is never written, or is written twice. ``` ### Clarifying Questions - Are social features (friends, chat, presence), multiplayer matchmaking and community features (reviews, forums, user-made content) in scope, or only the store, library and downloads? - How many players, concurrent clients and titles should the design assume, and how large is a typical build? - Must games be playable offline, and how strictly must ownership be enforced at launch? - Are seasonal sales and simultaneous worldwide releases in scope? They define the peak load. - Is the developer publishing pipeline in scope, including staged rollouts and rollbacks of builds? - Do purchases include in-game items, gifts and refunds, or only full games? ### What a Strong Answer Covers - Requirements split cleanly into store, purchase and entitlement, library, content delivery, and publishing - A catalog read path built for very heavy, cacheable traffic with regional pricing - A purchase flow that grants each entitlement exactly once and stays consistent with the payment - Content delivery for large, versioned builds: chunking, delta updates, a CDN, and launch-day surges - APIs and a data model for the catalog, orders, entitlements and builds - Failure handling for payment provider outages, CDN or region failures, and interrupted downloads - Capacity planning and observability for sales and major releases ### Follow-up Questions - A large sale starts at a fixed time and traffic jumps by orders of magnitude within seconds. What fails first, and how do you prepare? - How would a developer roll a new build out to a small share of players first, and roll it back if it crashes? - How do you let players launch owned games offline while still enforcing ownership? - How would you add a friends list with online presence for millions of concurrent clients?