Skip to content
System Designer

Easy · Media and streaming

Photo sharing

You are building a photo app. People post pictures and everyone else scrolls through them. Almost all the traffic is people looking at photos, and the photos take up far more room than anything else you store. Practise this easy system design problem for free with a Google or GitHub account.

The brief

You are building a photo app. People post pictures and everyone else scrolls through them. Almost all the traffic is people looking at photos, and the photos take up far more room than anything else you store.

Think of a photo app like Instagram.

Users, scale and requirements

Who uses it
30 million people a month
Audience in plain numbers
30,000,000 people per month
Normal peak
≈ 6,000 requests per second
Request mix
Read: 94%; Write: 5%; Upload: 1%
Speed for 99 of 100 requests
Read: ≈ 450 ms; Write: ≈ 450 ms; Upload: ≈ 4,000 ms
Successful requests
99.9%
Data safety
No acknowledged write may be lost.
Monthly budget
≈ $24,000
Data at rest
≈ 150 TB
Where users are
North America: 50%; Europe: 30%; Asia Pacific: 20%
Home region
North America
Waiting deadlines
Read: 900 seconds; Write: 3,600 seconds; Upload: 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.

  • About 1 million photos are posted per day (approx.).
  • The 150 TB figure is the busy recent set, not every photo ever posted (approx.).

Questions that shape the design

Do people edit a photo after posting?

No. A photo never changes after it is posted, only its caption and likes do. That makes photos very safe to copy near users.

Can a photo be lost?

Never. People treat these as memories. Once the app says "posted", the photo must survive.

How fast must a photo open?

The scored photo-read p99 target is 450 ms, including network travel. Uploads have a separate 4,000 ms target.

Do we keep every size of a photo?

Yes: the original plus a few smaller sizes. Together that is about 3 MB per photo.

The traffic day

Consumer traffic, busiest in the evening. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.

  1. 20:00 · Viral spike

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

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

  2. 14:00 · Cache stampede

    The cache empties (restart, purge, mass expiry) and every request rushes to the database at once.

    Recovery window: ≈ 300 seconds.

What a strong design has to handle

  • Photos never change. What does that let you do with copies of them?
  • A long CDN cache time means more photo views are served from the edge and the bill is lower, but a deleted photo can stay visible for a while.
  • Object storage is cheap per gigabyte but slower than a disk next to your server. It is the right home for photos and the wrong home for a like counter.

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