Start practising

SYSTEM DESIGN · CONCEPTS · RUNNING IT IN PRODUCTION · EPISODE 36

Back-of-the-Envelope Estimation

How to estimate scale in a system design interview: daily active users to requests per second, peak factor, read/write ratio, storage per year, bandwidth, cache size and number of servers, with handy round numbers and a worked example for a photo-sharing app.

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
1 / 10

Press play to hear the narration, or step through at your own pace. Every picture here is the same one used in the YouTube video.

Notes

Handy numbers

First, a few round numbers. A day is about a hundred thousand seconds. A year is about thirty million. So a million requests a day is roughly twelve per second, and a billion a day is about twelve thousand per second. Peak traffic is usually two to three times the average. Round aggressively; one significant digit is enough.

Numbers to memorise
1 day = 86,400 s ≈ 10⁵ s
1 month ≈ 2.5 × 10⁶ s
1 year ≈ 3 × 10⁷ s

1 million req/day ≈ 12 rps
1 billion req/day ≈ 12,000 rps

KB 10³ · MB 10⁶ · GB 10⁹
TB 10¹² · PB 10¹⁵
peak ≈ 2–3× average

Traffic

Worked example: a photo app with ten million daily users. Each views fifty photos a day: five hundred million reads, divided by a hundred thousand seconds, is about five thousand reads per second, fifteen thousand at peak. Each uploads one photo every five days: two million writes a day, about twenty per second. Two hundred and fifty to one: very read-heavy.

Photo app: traffic
10M daily active users
each views 50 photos/day
  → 500M reads/day
  → 500M / 10⁵ ≈ 5,000 rps
  → peak ×3 ≈ 15,000 rps

each uploads 0.2 photos/day
  → 2M writes/day ≈ 20 wps

read:write ≈ 250:1 → read-heavy

Storage

Storage: two million photos a day at two megabytes each is four terabytes a day, about one and a half petabytes a year, more with replication. But the metadata, a kilobyte per photo, is only two gigabytes a day. That split is a design decision: photos go to object storage, and the metadata fits comfortably in a database.

Photo app: storage
2M photos/day × 2 MB
  = 4 TB/day
  × 365 ≈ 1.5 PB/year
  × 3 replicas ≈ 4.5 PB

metadata: 2M × 1 KB
  = 2 GB/day ≈ 0.7 TB/year

→ photos in object storage
→ metadata fits a sharded DB

Bandwidth

Bandwidth: five thousand photo views a second at two hundred kilobytes each is a gigabyte per second, around eight gigabits, and three times that at peak. That's the number that tells you to serve images through a CDN and resize them to the screen, instead of from your own servers.

Bandwidth
5,000 photo views/s × 200 KB
(thumbnail-sized)
= 1 GB/s ≈ 8 Gbps average
peak ×3 ≈ 25 Gbps

→ serve images from a CDN
→ resize to the screen size

uploads: 20/s × 2 MB = 40 MB/s

Servers and cache

Servers: if one app server handles around two thousand simple requests a second, fifteen thousand at peak needs about eight, so run twelve across zones for headroom. Cache: keeping the hottest twenty percent of a day's metadata is about a hundred gigabytes, a small Redis cluster. Suddenly the design has numbers behind it.

Servers and cache
one app server ≈ 1,000–5,000 rps
(simple, mostly cached reads)
peak 15,000 rps / ~2,000
  ≈ 8 servers → run 12 (N+1, zones)

cache: hot 20% of a day's
metadata reads
  500M × 1 KB × 0.2 ≈ 100 GB
  → a small Redis cluster

So what

That's the real point: every number should lead to a decision. Two hundred fifty to one reads means caching, replicas and a CDN. One and a half petabytes a year means object storage with cheaper cold tiers. Twenty writes a second means a single primary database handles the metadata writes easily.

Numbers → decisions
  • 250:1 reads → cache, replicas,
  • CDN; optimise the read path
  • 1.5 PB/year → object storage,
  • lifecycle to cold tiers
  • 20 writes/s → one primary DB
  • is fine for metadata writes
  • 8 Gbps → CDN, not origin
  • 100 GB hot set → Redis

Mistakes

Common mistakes: being too precise, forgetting the peak factor, forgetting replication, and mixing up bits and bytes, a factor of eight. The biggest one is computing numbers that don't change the design. Do only the math that matters, and say every assumption out loud so the interviewer can correct it.

Common mistakes
  • too precise: 86,400 not needed
  • forgetting peak vs average
  • forgetting replication (×3)
  • mixing bits and bytes
  • (Gbps vs GB/s: ×8)
  • calculating things that do
  • not change the design
  • silently: always say
  • the assumptions out loud

Say it like this

In the interview, spend two to four minutes right after the requirements. Daily users and actions, average and peak requests per second, read to write ratio, storage per year split into data and metadata, bandwidth if there's media, and a rough server and cache count. Then always finish with: 'so this means…'

In the interview
  • 2–4 minutes, after requirements
  • state DAU and actions/day
  • avg + peak rps, read:write
  • storage/year (data vs metadata)
  • bandwidth if media
  • servers + cache size roughly
  • then: "so this means…"

Interview questions

How do you convert daily active users into requests per second?

Multiply users by actions per user per day and divide by about 100,000 seconds (86,400 rounded). Then multiply by a peak factor of 2–3 for peak traffic.

Why separate reads from writes in an estimate?

The read:write ratio drives the design: read-heavy systems lean on caching, replicas and CDNs; write-heavy systems need write-optimised storage, sharding and queues.

How do you estimate storage?

Writes per day × average object size × retention period, multiplied by the replication factor. Estimate large blobs (media) and small metadata separately because they go to different stores.

What is a reasonable throughput for a single application server?

Very roughly 1,000–5,000 simple requests per second, depending on work per request; use it to size the fleet and add headroom and N+1 redundancy across zones.

How big should a cache be?

Large enough for the hot working set, often estimated as around 20% of the daily read volume of the cached objects, since a small fraction of items receives most traffic.

What are common estimation mistakes?

Excessive precision, forgetting peak versus average, ignoring replication, confusing bits and bytes, and spending time on numbers that do not affect any design decision.

How much time should estimation take in an interview?

Two to four minutes after clarifying requirements, focusing on the few numbers that shape the architecture, with assumptions stated aloud.