AI InterviewSearch…Search problems, topics, or pages…Ctrl KGet started
Skip to content
SD notes

System Design · Note 14 of 22

Back-of-the-Envelope Estimation

Beginner · 6 min read · updated 14 November 2026

Quick answer

What is back-of-the-envelope estimation in system design?

Back-of-the-envelope estimation is a quick calculation, from stated assumptions, of the load a system must handle — requests per second, peak traffic, storage and bandwidth. It uses rounded numbers and orders of magnitude, not precision, to decide which parts of the design are needed: a cache, replicas, sharding or a CDN.

On this page
  1. Numbers to carry
  2. Latency numbers
  3. The method
  4. Worked example: a photo app
  5. Common mistakes
  6. Interview questions
  7. Common questions

An estimate turns vague scale ("lots of users") into numbers that pick the design. State assumptions, round hard, and keep the units.

Numbers to carry

  • Seconds in a day: 86,400 ≈ 10^5.
  • Powers of two read as powers of ten: 2^10 ≈ a thousand (KB), 2^20 ≈ a million (MB), 2^30 ≈ a billion (GB).
  • Sizes: a character ≈ 1 byte, an ID 8 bytes, a text row ≈ 1 KB, a photo ≈ hundreds of KB, a minute of video ≈ megabytes.
Powers of two you can say as powers of ten

2^10 is 1,024, close enough to a thousand to call it a kilobyte. That one shortcut turns powers of two into powers of ten.

0:01 / 0:13Step 1 of 5
Transcript · 5 steps

Latency numbers

  • Commonly quoted orders of magnitude, not benchmarks; hardware varies.
  • Memory answers in nanoseconds.
  • SSD reads in about a hundred microseconds.
  • Network round trip in a datacenter: about half a millisecond.
  • Disk seek: milliseconds. Across an ocean: a hundred milliseconds or more.
  • So: keep hot data in memory, avoid sequential round trips, put data near users.
Latency numbers on a human clock

Stretch time so an L1 cache read takes one second. The real figures are rough, widely quoted orders of magnitude; hardware varies.

0:01 / 0:16Step 1 of 6
Transcript · 6 steps

The method

  1. Assume daily active users (DAU) and actions per user. Say them out loud.
  2. Requests a day = DAU × actions.
  3. Average QPS = requests a day ÷ 86,400.
  4. Peak QPS = average × a peak factor (often 2–5×).
  5. Storage = writes a day × bytes each × days kept × copies.
  6. Bandwidth = QPS × bytes per request, in and out.

Worked example: a photo app

Assume 10M DAU, 50 photo views and 0.2 uploads per user a day, 500 KB a photo, a 3× peak.

From daily users to peak QPS, reads and writes

Start from assumptions said out loud: 10M daily users of a photo app, 50 views and 0.2 uploads each a day.

0:01 / 0:18Step 1 of 7
Transcript · 7 steps
  • Reads outnumber writes about 250 to 1: design the read path first.
  • About 17K reads a second at peak: several app servers and a cache.
Photo storage added up over 5 years

Storage is writes × size × time. 2M photos a day at about 500 KB each add 1 TB every day.

0:01 / 0:16Step 1 of 7
Transcript · 7 steps
  • About 1 TB a day: object storage with metadata in a database.
  • Copies multiply the total, so count them.
Bandwidth in and out, and what a CDN takes away

Bandwidth is QPS × bytes per request. Uploads bring in about 11.6 MB/s — a thin line next to what goes out.

0:01 / 0:11Step 1 of 4
Transcript · 4 steps
  • Outbound traffic dwarfs inbound: put a CDN in front.

Common mistakes

  • Skipping assumptions: the interviewer cannot follow, or correct, a number with no source.
  • Forgetting the peak: average load hides the evening spike.
  • Mixing bits and bytes: network links are sold in bits per second.
  • Chasing precision: 5,787 and 6,000 lead to the same design.
  • Estimating and then ignoring the result: every number should change a box in the diagram.

Interview questions

  • How many seconds are in a day? 86,400 — round to 10^5 and say so.
  • How do you get peak QPS? Average QPS times a stated peak factor, often 2–5×.
  • Why estimate storage per year? It decides whether data fits on one machine or needs sharding and object storage.
  • Your service sends 10 GB/s. What follows? One server's network card cannot carry it: spread it over many servers and serve static bytes from a CDN.

Next: How to Answer a System Design Interview · Before this: Design a URL Shortener

Common questions

How do you calculate QPS from daily active users?

Multiply daily active users by the requests each makes a day, then divide by 86,400, the seconds in a day. Multiply the average by a peak factor, often two to five, which you state as an assumption.

Why is 86,400 rounded to 100,000?

Dividing by 10^5 is easy in your head and keeps the answer within the same order of magnitude. The result is about 14% low, which an estimate can live with; say that you rounded.

How do you estimate storage for a system?

Multiply writes per day by the bytes each write stores and by the days you keep the data. Then multiply by the number of copies kept for durability, and add room for indexes and metadata.

Which latency numbers should I remember for interviews?

Orders of magnitude, not exact values: memory in nanoseconds, an SSD read around a hundred microseconds, a round trip inside a datacenter around half a millisecond, a disk seek in milliseconds and a cross-ocean round trip around a hundred milliseconds or more.

How precise does an estimate need to be?

Within an order of magnitude. Its job is to tell you whether one server is enough, whether reads dominate writes and whether data fits on one machine — decisions that do not change between 5,000 and 6,000 QPS.

AI InterviewGet started

Back-of-the-Envelope Estimation for System Design

Estimate QPS, peak load, storage and bandwidth in a system design interview: powers of two, latency numbers and a worked example, animated step by step.

  • Subject: System Design
  • Level: Beginner
  • Reading time: 6 min
  • Updated: 2026-11-14

What is back-of-the-envelope estimation in system design?

Back-of-the-envelope estimation is a quick calculation, from stated assumptions, of the load a system must handle — requests per second, peak traffic, storage and bandwidth. It uses rounded numbers and orders of magnitude, not precision, to decide which parts of the design are needed: a cache, replicas, sharding or a CDN.

An estimate turns vague scale ("lots of users") into numbers that pick the design. State assumptions, round hard, and keep the units.

Numbers to carry

  • Seconds in a day: 86,400 ≈ 10^5.
  • Powers of two read as powers of ten: 2^10 ≈ a thousand (KB), 2^20 ≈ a million (MB), 2^30 ≈ a billion (GB).
  • Sizes: a character ≈ 1 byte, an ID 8 bytes, a text row ≈ 1 KB, a photo ≈ hundreds of KB, a minute of video ≈ megabytes.
powerexact valuesayunitoff by2^101,024≈ 1 thousandKB+2.4%2^201,048,576≈ 1 millionMB+4.9%2^301,073,741,824≈ 1 billionGB+7.4%2^401,099,511,627,776≈ 1 trillionTB+10.0%2^501,125,899,906,842,624≈ 1 quadrillionPB+12.6%
Powers of two you can say as powers of ten.
  1. 2^10 is 1,024, close enough to a thousand to call it a kilobyte. That one shortcut turns powers of two into powers of ten.
  2. 2^20 = 1,048,576, about a million: one MB. Saying 10^6 instead is 4.9% low.
  3. 2^30 = 1,073,741,824, about a billion: one GB. Saying 10^9 instead is 7.4% low.
  4. 2^40 = 1,099,511,627,776, about a trillion: one TB. Saying 10^12 instead is 10.0% low.
  5. 2^50 is about a quadrillion: one PB. Every ten powers of two is roughly three powers of ten; the shortcut errs by 2.4% at KB and 12.6% at PB — fine for an estimate.

Latency numbers

  • Commonly quoted orders of magnitude, not benchmarks; hardware varies.
  • Memory answers in nanoseconds.
  • SSD reads in about a hundred microseconds.
  • Network round trip in a datacenter: about half a millisecond.
  • Disk seek: milliseconds. Across an ocean: a hundred milliseconds or more.
  • So: keep hot data in memory, avoid sequential round trips, put data near users.
operation (approx.)realif 1 ns were 1 secondL1 cache read1 ns1 sMain memory read100 ns1.7 minSSD random read100 µs1.2 daysDatacenter round trip500 µs5.8 daysSpinning-disk seek10 ms3.8 monthsRound trip across an ocean150 ms4.8 years
Latency numbers on a human clock.
  1. Stretch time so an L1 cache read takes one second. The real figures are rough, widely quoted orders of magnitude; hardware varies.
  2. Main memory read: about 100 ns. On the stretched clock that is 1.7 min, 100× the line above.
  3. SSD random read: about 100 µs. On the stretched clock that is 1.2 days, 1,000× the line above.
  4. Datacenter round trip: about 500 µs. On the stretched clock that is 5.8 days, 5× the line above.
  5. Spinning-disk seek: about 10 ms. On the stretched clock that is 3.8 months, 20× the line above.
  6. Round trip across an ocean: 150 ms, or 4.8 years on this scale. Memory is instant, a network hop is days, a disk seek months — cache hot data and avoid round trips.

The method

  1. Assume daily active users (DAU) and actions per user. Say them out loud.
  2. Requests a day = DAU × actions.
  3. Average QPS = requests a day ÷ 86,400.
  4. Peak QPS = average × a peak factor (often 2–5×).
  5. Storage = writes a day × bytes each × days kept × copies.
  6. Bandwidth = QPS × bytes per request, in and out.

Worked example: a photo app

Assume 10M DAU, 50 photo views and 0.2 uploads per user a day, 500 KB a photo, a 3× peak.

10M daily users× 50500M views / day× 0.22M uploads / day÷ 86,400≈ 5,787 reads/s÷ 86,400≈ 23 writes/s× 3 peak≈ 17.4K reads/s× 3 peak≈ 69 writes/s
From daily users to peak QPS, reads and writes.
  1. Start from assumptions said out loud: 10M daily users of a photo app, 50 views and 0.2 uploads each a day.
  2. Each of 10M daily users views 50 photos: 500M reads a day.
  3. One user in 5 uploads a photo a day: 2M writes a day.
  4. A day is 86,400 seconds, so reads average 5,787 per second. Rounding the day to 10^5 seconds gives 5,000 — the same order of magnitude.
  5. Writes average only 23 per second: about 250 reads for every write, so this design is read-heavy.
  6. Traffic bunches into evenings. With an assumed peak of 3× the average, the read path must carry about 17.4K per second.
  7. Peak writes are about 69 per second — one database takes that easily; the reads are what need caches and replicas.
  • Reads outnumber writes about 250 to 1: design the read path first.
  • About 17K reads a second at peak: several app servers and a cache.
2M photos/day × 500 KB = 1 TB/dayyear 11.09 PByear 22.19 PByear 33.29 PByear 44.38 PByear 55.47 PB
Photo storage added up over 5 years.
  1. Storage is writes × size × time. 2M photos a day at about 500 KB each add 1 TB every day.
  2. After one year: 1 TB a day × 365 days = 365 TB.
  3. Year 2 adds another 365 TB, since photos are rarely deleted: 730 TB kept so far.
  4. Year 3 adds another 365 TB, since photos are rarely deleted: 1.09 PB kept so far.
  5. Year 4 adds another 365 TB, since photos are rarely deleted: 1.46 PB kept so far.
  6. Year 5 adds another 365 TB, since photos are rarely deleted: 1.82 PB kept so far.
  7. Keep 3 copies for durability and 5 years becomes about 5.47 PB. Numbers this size decide the store: object storage, not a database row.
  • About 1 TB a day: object storage with metadata in a database.
  • Copies multiply the total, so count them.
In: uploads23/s × 500 KB11.6 MB/sOut: views5,787/s × 500 KB2.9 GB/sOut at peak× 38.7 GB/sOrigin, CDN 90%× 0.1868.1 MB/s
Bandwidth in and out, and what a CDN takes away.
  1. Bandwidth is QPS × bytes per request. Uploads bring in about 11.6 MB/s — a thin line next to what goes out.
  2. Views send out about 2.9 GB/s on average, 250× the inbound rate, because every photo is seen many times.
  3. At the assumed 3× peak that is 8.7 GB/s, roughly 69 Gbit/s — more than a server's network card can send.
  4. If a CDN answers 90% of views from its edges, the origin sends only 868.1 MB/s. The estimate is what tells you the CDN is required.
  • Outbound traffic dwarfs inbound: put a CDN in front.

Common mistakes

  • Skipping assumptions: the interviewer cannot follow, or correct, a number with no source.
  • Forgetting the peak: average load hides the evening spike.
  • Mixing bits and bytes: network links are sold in bits per second.
  • Chasing precision: 5,787 and 6,000 lead to the same design.
  • Estimating and then ignoring the result: every number should change a box in the diagram.

Interview questions

  • How many seconds are in a day? 86,400 — round to 10^5 and say so.
  • How do you get peak QPS? Average QPS times a stated peak factor, often 2–5×.
  • Why estimate storage per year? It decides whether data fits on one machine or needs sharding and object storage.
  • Your service sends 10 GB/s. What follows? One server's network card cannot carry it: spread it over many servers and serve static bytes from a CDN.

Next: How to Answer a System Design Interview · Before this: Design a URL Shortener

Common questions

How do you calculate QPS from daily active users?

Multiply daily active users by the requests each makes a day, then divide by 86,400, the seconds in a day. Multiply the average by a peak factor, often two to five, which you state as an assumption.

Why is 86,400 rounded to 100,000?

Dividing by 10^5 is easy in your head and keeps the answer within the same order of magnitude. The result is about 14% low, which an estimate can live with; say that you rounded.

How do you estimate storage for a system?

Multiply writes per day by the bytes each write stores and by the days you keep the data. Then multiply by the number of copies kept for durability, and add room for indexes and metadata.

Which latency numbers should I remember for interviews?

Orders of magnitude, not exact values: memory in nanoseconds, an SSD read around a hundred microseconds, a round trip inside a datacenter around half a millisecond, a disk seek in milliseconds and a cross-ocean round trip around a hundred milliseconds or more.

How precise does an estimate need to be?

Within an order of magnitude. Its job is to tell you whether one server is enough, whether reads dominate writes and whether data fits on one machine — decisions that do not change between 5,000 and 6,000 QPS.

← Design a URL Shortener · How to Answer a System Design Interview →