Skip to content
System Designer

Hard · Core building blocks

Object storage service

Customers store billions of files, from tiny pictures to huge videos, and fetch them by name. The service must never lose a file, scale without a limit and stay cheap. Most files are written once and rarely read again. Practise this hard system design problem for free with a Google or GitHub account.

The brief

Customers store billions of files, from tiny pictures to huge videos, and fetch them by name. The service must never lose a file, scale without a limit and stay cheap. Most files are written once and rarely read again.

Think of a cloud file store like Amazon S3.

Users, scale and requirements

Who uses it
5 million developers and apps (approx.)
Audience in plain numbers
5,000,000 users or devices
Normal peak
≈ 12,000 requests per second
Request mix
Read: 75%; Upload: 15%; Write: 10%
Speed for 99 of 100 requests
Read: ≈ 400 ms; Upload: ≈ 4,000 ms; Write: ≈ 400 ms
Successful requests
99.95%
Data safety
No acknowledged write may be lost.
Monthly budget
≈ $170,000
Data at rest
≈ 2,000 TB
Where users are
North America: 50%; Europe: 30%; Asia Pacific: 20%
Home region
North America
Waiting deadlines
Read: 900 seconds; Upload: 3,600 seconds; Write: 3,600 seconds
Required proofs
Managed encryption keys

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

  • Uploads average a few MB. Use the request mix to work out their peak rate.
  • Around 2 PB stored, growing every day (approx.).
  • All numbers are rough approximations.

Questions that shape the design

Can a file change after it is saved?

A new upload replaces it whole. Files are never edited in place.

How safe must a file be?

Never lost. Once saved, a file must be there years later, even if a data centre burns down.

Are all files read equally?

No. A small share is read all the time and most are almost never touched.

The traffic day

Traffic following users around the world. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

  1. 10:00 · Viral spike

    A post blows up. Traffic climbs to several times normal within minutes.

    Traffic reaches 3 times the scheduled load; rises over 600 seconds, holds for 3,600 seconds and eases over 3,600 seconds.

  2. 15:00 · Zone outage

    An availability zone loses power or network access.

    Duration: ≈ 3,600 seconds.

  3. 19: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

  • Two different jobs hide here: finding a file by name, and storing its bytes. Should one database do both?
  • Publish only complete durable objects and reclaim unreferenced pieces safely.
  • Keeping several copies protects against loss but multiplies the storage bill. Erasure coding gives similar safety for less.
  • Cold tiers are cheap to keep and slow or costly to read. Move a file there only when it is truly idle.

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