Katkat
Back

Design a Digital Game Store and Distribution Platform Like Steam

OpenAISoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

A system design interview question asking you to design a digital game store and distribution platform like Steam, covering the catalog, purchases, player libraries, and game downloads and updates. It tests content delivery for very large builds, entitlement consistency with payments, and handling traffic spikes during sales and launches.

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.

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?

Hints

Hint 1

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 2

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.

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?