The interviewer asks how much storage a photo app needs, and I freeze

System Design · Foundations
20 min read, about 1 h with practice

Concept
Asked often: high
Reviewed 2026-11

See the problem

“Design a photo-sharing app. About 10 million daily users.” Then the interviewer waits. How many servers? How much storage? You start dividing 20,000,000 by 86,400 in your head, lose a zero, and the clock keeps running.

Define the task

What you have: a few facts from the interviewer, and guesses you are allowed to make.
What you want: requests a second (average and peak), storage a day and over 5 years, and how many servers, in about two minutes, out loud.
The hard part: exact maths is slow and easy to get wrong under pressure. Rough maths is fast, but only if you round the same way every time.

Pause and think

Hint 1 of 3

A day has 86,400 seconds. Round it to 100,000.

Hint 2 of 3

20,000,000 ÷ 100,000 = 200.

Hint 3 of 3

Rounding the day down to 100,000 makes the answer about 15% low. That is fine for an estimate.

Understand the idea

An estimate is a recipe with four steps:

Say your guesses. “10 million daily users, 2 photos each a day, 2 MB a photo, 20 views per photo.” The interviewer can correct a guess; they can’t correct a number they never heard.
Traffic. Per day ÷ 100,000 = per second. Multiply by 2 or 3 for the peak.
Storage. Per day × size, then × 365 × years.
Servers. Peak ÷ what one server handles, rounded up, plus a spare.

Powers of ten keep the zeros right: thousand (10³, KB), million (10⁶, MB), billion (10⁹, GB), trillion (10¹², TB), 10¹⁵ (PB). A million things of a megabyte each is a terabyte.

Watch the photo app’s numbers build up. Change the daily users below the player.

A photo app, estimated step by step

Step 1: traffic

Step 1 of 5. A photo app with 10 million daily users. Each uploads 2 photos a day, of about 2 MB. Each photo is viewed about 20 times.

Speed Ask me first Show as text

The tests check every number on this page with this file:

"""Back-of-the-envelope helpers: round hard, say the sums out loud.

A day has 86,400 seconds; call it 100,000 (10^5) for quick sums.
"""

DAY_S = 86_400
ROUGH_DAY_S = 100_000


def per_second(per_day: float, rough: bool = True) -> float:
    return per_day / (ROUGH_DAY_S if rough else DAY_S)


def storage_bytes(per_day: float, size_bytes: float, years: float) -> float:
    return per_day * size_bytes * 365 * years


def servers(peak_per_second: float, one_handles: float, spare: int = 1) -> int:
    whole = int(-(-peak_per_second // one_handles))  # Round up.
    return whole + spare


def photo_app(
    daily_users: float = 10e6,
    photos_per_user: float = 2,
    photo_bytes: float = 2e6,
    views_per_photo: float = 20,
    peak: float = 3,
) -> dict[str, float]:
    """The lesson's photo app, every number from the stated guesses."""
    uploads_day = daily_users * photos_per_user
    uploads_s = per_second(uploads_day)
    views_s = uploads_s * views_per_photo
    return {
        "uploads_day": uploads_day,
        "uploads_s": uploads_s,
        "peak_uploads_s": uploads_s * peak,
        "views_s": views_s,
        "peak_views_s": views_s * peak,
        "storage_day": uploads_day * photo_bytes,
        "storage_5y": storage_bytes(uploads_day, photo_bytes, 5),
        "upload_bandwidth_bytes_s": uploads_s * photo_bytes,
    }

Climb the ladder

Each rung estimates the same photo app: 10 million daily users, 2 photos each, 2 MB a photo, 20 views per photo.

The idea: Divide 20,000,000 by 86,400 exactly, then carry the decimals.

The answer is right, and nobody needs the decimals.

Gets: about 231.5 uploads a second, slowly
Weak spot: minutes lost, zeros dropped
Why: Long division under pressure is slow, and one slip makes everything after it wrong.

Where it breaks: time and mistakes. Two minutes on one division leaves no time for the design, and a lost zero turns 40 TB into 4 TB.

The idea: A day is 100,000 seconds: 20 million ÷ 100,000 = 200 uploads a second; 200 × 20 = 4,000 views a second.

The waste in Okay: precision nobody uses.

Gets: seconds, within about 15%
Weak spot: no peak, no storage, no point
Why: Dividing by 10⁵ is moving the decimal point; the tests show the rough answer is under 15% off.

Where it breaks: an average alone sizes nothing. Servers must handle the peak, and the biggest cost here is storage, which this step never reached.

The idea: Guesses, traffic with a peak (×3), storage a day and over 5 years, servers with a spare, then say what drives the design.

The waste in Better: it stopped before the numbers that shape the design. “40 TB a day, read 20 times each” says: photos in object storage, served by a CDN, and only small rows in the database.

Gets: 12,000 views a second at peak; 40 TB a day; about 73 PB in 5 years; 7 servers
Weak spot: numbers are only as good as the guesses
Why: Each step is one multiplication or division of round numbers, and each one is said out loud.

When Best isn’t best: don’t estimate what doesn’t change the design. If the interviewer says “assume it fits on one machine”, move on.

Draw it yourself

Answer the sizing question first, then draw a design the numbers call for.

Step 1: A photo app, sized

10 million daily users upload 2 photos a day, about 2 MB each.
Each photo is viewed 20 times. Peaks are 3 times the average.
Size the app servers first, then draw the design.

Solid arrow: sends requests toDashed arrow: copies data to

Watch the traffic

Send 10 requests through your board and see where each one goes. Then make a part fail and send them again.

SendReadsWritesBackground jobs

Make a part fail

How requests move

Requests start at the Client and follow your arrows. Reads try a cache first (4 in 5 are found there), then a read replica, then the database. Writes go to the database. Background jobs go on a queue, and a worker saves them. A load balancer skips a part that is down; nothing else can.

Compare

Number	Recipe	Photo app
Uploads a second	20 million ÷ 100,000	200
Views a second	200 × 20	4,000
Peak views a second	4,000 × 3	12,000
App servers	12,000 ÷ 2,000, + 1 spare	7
Storage a day	20 million × 2 MB	40 TB
Storage in 5 years	40 TB × 365 × 5	about 73 PB
Upload bandwidth	200 × 2 MB a second	400 MB a second

Common mistakes and edge cases

Forgetting the peak. Traffic is not flat. Size servers for 2 to 3 times the average.
Forgetting copies. Storage is usually kept 3 times for safety, and photos often in several sizes. Say whether you count that.
Bits and bytes. Network speeds are in bits: 1 Gbit/s is about 125 MB/s.
Estimating everything. Pick the numbers that decide the design: the biggest traffic, the biggest storage, the read/write ratio.
Silent guesses. A number with no stated guess behind it can’t be checked. Say “I’ll assume 2 photos per user a day”.

Say it in the interview

Questions to ask first

How many daily users? How many actions each a day?
How big is one item, and how long do we keep it?
How many reads for each write?

A 60-second walkthrough

“I’ll assume 10 million daily users, 2 photos each, 2 MB a photo, and 20 views per photo. That’s 20 million uploads a day; with 100,000 seconds a day, about 200 uploads a second, and 4,000 views a second, 12,000 at peak. At 2,000 a server that’s 6 servers plus a spare, before any CDN. Storage is 20 million times 2 MB, 40 TB a day, about 73 PB over 5 years. So photos go to object storage and are served through a CDN. The database holds only metadata.”

Likely follow-ups

How much metadata? 20 million rows a day of about 200 bytes is 4 GB a day, about 1.5 TB a year: big, but a database can hold it, with partitioning later.
What if half the users are on one continent? The peak is sharper, because their evenings line up. Use 3 to 5 times the average.
Bandwidth out? 12,000 views a second × 2 MB is 24 GB a second at peak, which is why a CDN must serve the views.

Red flags interviewers notice

No numbers at all, or numbers with no guesses behind them.
Exact arithmetic that eats five minutes.
Estimates that never change the design.

Practice

1. Chat app numbers (easy)

50 million daily users send 40 messages each a day; a message is about 100 bytes. Messages per second (average and peak), and storage per day?

Hint 1 of 3

Messages a day: 50 million × 40.

Hint 2 of 3

Per second: divide by 100,000; peak: × 3.

Hint 3 of 3

Storage: messages a day × 100 bytes.

Show the answers

The idea: 50 million × 40 = 2 billion messages a day.

Right, and only the first step.

Gives: the daily total
Weak spot: no rate, no storage
Why: A daily total sizes nothing yet.

The idea: 2 billion ÷ 100,000 = 20,000 a second; × 3 = 60,000 at peak.

60,000 writes a second is far past one SQL database: a hint to split the data.

Gives: what the servers face
Weak spot: storage missing
Why: Peak writes size the database and the servers.

The idea: Plus storage: 2 billion × 100 bytes = 200 GB a day, about 73 TB a year.

Say it: “60,000 writes a second and 73 TB a year, so I’ll partition by conversation.”

Gives: the whole picture
Weak spot: none
Why: Many small writes and steady growth point to a store split by conversation.

2. Logs per day (medium)

500 servers each write 100 log lines a second, of about 200 bytes. Keep 30 days. How much storage, and can one search cluster take the writes?

Hint 1 of 3

Lines a second across all servers: 500 × 100.

Hint 2 of 3

Bytes a second, then × 100,000 for a day (or 86,400 if you like).

Hint 3 of 3

Then × 30 days.

Show the answers

The idea: 100 × 200 bytes = 20 KB a second per server.

Small per server, large together.

Gives: one server’s view
Weak spot: the total is missing
Why: The system sees all 500 at once.

The idea: 50,000 lines a second; 10 MB a second; about 1 TB a day (10 MB × 100,000).

With 86,400 seconds it is 864 GB: close enough.

Gives: daily size
Weak spot: retention missing
Why: Rough day: 10 MB × 10⁵ = 10¹² bytes.

The idea: About 30 TB for 30 days, plus replicas; 50,000 writes a second spread over several nodes; old days moved to cheap object storage.

Sampling noisy debug lines can cut the volume a lot.

Gives: a design, not just a number
Weak spot: none
Why: Recent logs need fast search; old ones only need to be kept.

3. Video storage (hard)

1 million videos are uploaded a day, 10 minutes each on average. Each is stored at 3 qualities, about 1 GB an hour in total across the three. Storage a year?

Hint 1 of 3

Hours of video a day: 1 million × 10 minutes.

Hint 2 of 3

Storage a day: hours × 1 GB.

Hint 3 of 3

Then × 365, and say whether you count copies for safety.

Show the answers

The idea: 1 million × 10 = 10 million minutes a day.

Convert: 10 million minutes is about 170,000 hours.

Gives: the volume
Weak spot: no bytes yet
Why: Storage needs a size per minute or per hour.

The idea: About 170,000 hours × 1 GB = about 170 TB a day.

The three qualities are already inside the 1 GB an hour.

Gives: daily growth
Weak spot: the year and copies missing
Why: 10 million ÷ 60 is about 167,000 hours; round to 170,000.

The idea: 170 TB × 365 is about 62 PB a year; with 3 copies for safety, about 186 PB.

Move videos nobody watches to colder, cheaper storage after a few months.

Gives: the real bill
Weak spot: none
Why: Copies multiply storage; say whether you include them.

Check yourself

Fill in the answerAbout how many requests a second is 5 million requests a day? (Round a day to 100,000 seconds; type a number.)Your answer
Multiple choice10 million photos a day, 3 MB each. Storage a day?
30 GB300 GB30 TB3 PB
Fill in the answerPeak is 15,000 requests a second and one server handles 2,000. How many servers, with one spare? (Type a number.)Your answer
Multiple choiceWhy say your guesses (users, sizes, ratios) out loud first?
It fills timeThe interviewer can correct a guess before every number is built on itGuesses must be exactIt is a rule of the interview

Cheat sheet

A day is 86,400 seconds: use 100,000. A month is about 2.6 million seconds.
1 million a day is about 10 a second. Peak is 2 to 3 times the average.
KB 10³, MB 10⁶, GB 10⁹, TB 10¹², PB 10¹⁵. A million MB is a TB.
Servers = peak ÷ one server’s limit, rounded up, plus a spare.
Say every guess out loud, and end with what the numbers mean for the design.

Go deeper

Jeff Dean: Numbers everyone should know (talk slides, 2009)
Before this: Latency numbers.
Use it: Design a URL shortener starts with these sums.

Can you do these now?

If you’re not sure of any of these, scroll back to that part before moving on.

Turn daily users into requests a second, average and peak
Estimate storage a day and over years, with the zeros right
Size servers from a peak and one server’s limit, with a spare
Say which number drives the design, out loud, in under two minutes

Status: Not started

The interviewer asks how much storage a photo app needs, and I freeze

See the problem

Define the task

Pause and think

Understand the idea

Climb the ladder

Exact maths in your head

Round to powers of ten

The full recipe, out loud

Draw it yourself

Step 1: A photo app, sized

Watch the traffic

Compare

Common mistakes and edge cases

Say it in the interview

Practice

1. Chat app numbers (easy)

Messages a day only

Rates

Rates and storage

2. Logs per day (medium)

Per server

Totals

Totals, retention and the plan

3. Video storage (hard)

Minutes a day

Bytes a day

A year, with copies

Check yourself

Cheat sheet

Go deeper

Can you do these now?