Digital Game Store and Distribution Platform (Steam)

0) Problem Restatement

Design a digital game store like Steam or the Epic Games Store. Users browse a catalog, buy games (often on sale), and see them in their library. They download large game files (tens of GB) and get patches when games update. Refunds, regional prices, promotions and license checks when a game starts are all part of it. Launch days bring huge spikes: millions of people buying and downloading the same game at the same hour.

1) Requirements

1.1 Functional

• Catalog: browse, search, game pages and prices per region.
• Cart, purchase, and gifting.
• Library and entitlements (who owns which game and DLC).
• Download and install, and update with patches.
• Refunds (e.g., within 14 days and under 2 hours played).
• Promotions and discount codes.

1.2 Non-Functional

• Money correctness: never charge twice, never grant a game without payment (or the reverse).
• Fast downloads worldwide.
• Survive launch spikes for purchases and downloads.
• High availability for game launch (license checks shouldn't stop people from playing).

1.3 Scale Estimates

• 100M users, 5M purchases/day ≈ 60/sec, with spikes of 5K/sec at big launches or sales.
• Downloads: a 60 GB launch × 2M buyers on day one = 120 PB of traffic. Only a CDN can deliver that.

1.4 API Design

• GET /v1/games/{id}?region=IN (price in local currency)
• POST /v1/orders (Idempotency-Key) { items: [{ game_id, edition }], promo_code? }
• GET /v1/users/me/library
• GET /v1/games/{id}/builds/latest/manifest → the list of files and chunks for download
• POST /v1/orders/{id}/refund
• POST /v1/licenses/check { game_id, device_id } → a signed license token

2) High-Level Architecture

2.1 Overview

• Catalog service + search index + CDN-cached game pages.
• Pricing & promotions: regional prices, sale schedules and discount codes.
• Order service: the order state machine, integrated with payments.
• Entitlement service: the source of truth for ownership. It grants on successful payment and revokes on refund or chargeback.
• Content pipeline: developers upload builds, and the pipeline chunks, compresses and signs them.
• CDN: serves game chunks.
• License service: issues signed tokens that allow offline play for a period.

2.2 Architecture Diagram

flowchart LR
    U["Player"] --> CAT["Catalog + Pricing"]
    U --> ORD["Order Service"]
    ORD --> PAY["Payment Service"]
    ORD -->|"paid event"| ENT["Entitlement Service"]
    ENT --> EDB[("Entitlements DB")]
    U --> LIB["Library"]
    LIB --> ENT
    DEV["Developers"] --> PIPE["Build pipeline - chunk, sign"]
    PIPE --> OS[("Build storage")]
    OS --> CDN["CDN"]
    U -->|"download chunks"| CDN
    U --> LIC["License Service - signed tokens"]
    LIC --> ENT

3) Data Model

games:         game_id, title, developer_id, release_at, status
prices:        game_id, region, currency, amount, valid_from, valid_to
orders:        order_id, user_id, items, total, currency, status (created, paid, fulfilled, refunded), idempotency_key
entitlements:  user_id, game_id, source (purchase|gift|promo), order_id, status (active/revoked), granted_at
builds:        game_id, build_id, version, manifest_key, status (staged, live, rolled_back)

4) Key Flows

4.1 Purchase

1. The client creates an order with an idempotency key. The price is locked at order time.
2. Payment is authorized and captured (see the payment system design).
3. On a successful payment event, the entitlement service grants the game. The grant is idempotent (by order_id), so a replayed event can't grant twice.
4. The game appears in the library, and the download can start.

4.2 Download and patch

1. The client gets the manifest: the list of files, each split into chunks identified by content hash.
2. It downloads only the chunks it doesn't have, from the nearest CDN edge, in parallel, and verifies each hash.
3. Patching: a new build's manifest shares most chunks with the old one, so the client only downloads the changed chunks. A 2 GB patch instead of 60 GB.

4.3 Refund

Check the policy (time since purchase, hours played), refund through payments, and revoke the entitlement. The next license check fails, so the game can't be launched.

5) Deep Dive A — Launch-day spikes

• Pre-load: let buyers download encrypted game files days before release. On launch, only a small decryption key is released. This spreads 120 PB over days.
• CDN capacity: multiple CDN providers, prefilled with the build before launch, and peer-assisted delivery where allowed.
• Purchases: a queue in front of order creation, pre-scaled services, and cached catalog pages (a game page is identical for everyone in a region).
• Download pacing: clients back off and retry with jitter when a CDN returns errors.

6) Deep Dive B — Entitlements and licenses

• The entitlement DB is the single source of truth for ownership. Orders, gifts, promos and refunds all go through it.
• License tokens: when a game starts, it asks for a signed token (valid e.g. 30 days) with user, game, device, expiry. The game verifies the signature offline, so short outages of the license service don't stop play.
• Fraud: chargebacks revoke entitlements, and stolen cards trigger holds. Rate-limit gift purchases, which are a common fraud path.
• Staged rollouts for builds: release a new patch to 5% of players first, watch crash rates, then 100%. Keep a kill switch to roll back to the previous build manifest.

7) Trade-offs & Alternatives

8) Common Follow-up Questions

• "Regional pricing and taxes?" Store prices per region and currency, pick the region from the billing address (not just IP), and add tax at checkout using a tax service.
• "Flash sales?" Schedule price changes ahead of time and pre-warm caches. The price in the order is what counts, even if the sale ends during checkout.
• "Family sharing?" Model it as entitlements that point to the owner's entitlement, with limits on concurrent play.

9) Wrap-Up

Handle purchases with idempotent orders and payments, and let a dedicated entitlement service grant and revoke ownership as the single source of truth. Deliver games as content-hashed chunks through CDNs so patches only download changed chunks, pre-load big launches and release keys at launch time, and issue signed offline license tokens so play doesn't depend on the store being up.