Skip to content
System Designer

Medium · Games

Patch day downloads

A popular game ships a 5 GB update at 10 am. Millions of players press Update within the same hour. The files are identical for everyone, so the work is moving huge amounts of data without a huge bill, while players still log in and play. Practise this medium system design problem for free with a Google or GitHub account.

The brief

A popular game ships a 5 GB update at 10 am. Millions of players press Update within the same hour. The files are identical for everyone, so the work is moving huge amounts of data without a huge bill, while players still log in and play.

Think of a big game update.

Users, scale and requirements

Who uses it
12 million players a month (approx.)
Audience in plain numbers
12,000,000 people per month
Normal peak
≈ 120 requests per second
Request mix
Stream chunk: 75%; Read: 10%; Sign-in: 10%; Write: 5%
Speed for 99 of 100 requests
Stream chunk: ≈ 2,000 ms; Read: ≈ 400 ms; Sign-in: ≈ 1,000 ms; Write: ≈ 400 ms
Successful requests
99.5%
Data safety
At most 1 minute of writes may be lost.
Monthly budget
≈ $34,000
Data at rest
≈ 30 TB
Where users are
North America: 40%; Europe: 35%; Asia Pacific: 25%
Home region
North America
Waiting deadlines
Stream chunk: 900 seconds; Read: 900 seconds; Sign-in: 900 seconds; Write: 3,600 seconds

≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.

  • The update is about 5 GB, cut into 8 MB pieces (approx.).
  • Most pieces are asked for by millions of players in one hour (approx.).
  • All numbers are rough approximations.

Questions that shape the design

Is every player downloading the same file?

Yes, for each platform. The same file is requested millions of times.

Can downloads be slow?

A bit. Players accept a few minutes. Logging in must stay quick.

Does the bill matter?

A great deal. Moving data out is the largest cost of the day.

The traffic day

A quiet baseline followed by the scheduled rush. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

  1. 10:00 · Flash crowd

    A scheduled launch brings a sudden rush of requests.

    Traffic reaches 3 times the scheduled load; rises over 30 seconds, holds for 900 seconds and eases over 1,800 seconds.

  2. 12:00 · Cost blowout

    A crawler hits uncached pages all day, and every pay-per-use part of the bill multiplies.

    Traffic for Read, Search reaches 1.5 times the scheduled load; rises over 600 seconds, holds for 21,600 seconds and eases over 600 seconds. Other request types keep their scheduled load. Billed usage multiplier: 3. Duration: ≈ 21,600 seconds.

What a strong design has to handle

  • Millions ask for the same pieces. What should answer them, and what should never see them?
  • Distribute immutable patch pieces and activate only a verified complete version.
  • A week-long copy time almost removes origin load. It needs versioned file names, so a fixed file is never served stale.
  • A cheaper bulk CDN tier costs less per terabyte but is slower. Many studios use it for patches.

Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.

Concepts to practise

Related problems