In this article
Before you start
Why interviewers ask this
An interviewer asks for an estimate to see whether you can size a system before you design it, because a design for ten requests a second and a design for a million are different systems. In a system design round the estimate usually comes early: how many requests, how much storage, how much bandwidth, how many machines.
A weak answer either refuses to guess or computes to six digits. A strong answer states every assumption aloud, rounds on purpose, shows the multiplication, and says how wrong it could be. The same skill carries into machine learning system design and generative AI system design, where the numbers are tokens and graphics processing unit (GPU) memory instead of photos.
Back-of-the-envelope estimation from first principles
In plain words
- Back-of-the-envelope estimation
- Back-of-the-envelope estimation is a method of getting an approximate answer to a sizing question by listing assumptions, rounding every number to one or two significant digits and multiplying, quickly enough to do on scrap paper. Its aim is the right power of ten, not the right last digit.
- Order of magnitude
- An order of magnitude is a factor of ten. Two quantities are in the same order of magnitude when one is less than about ten times the other, and an estimate within a factor of ten of the true value has a digit count that is right or off by one.
- Queries per second
- Queries per second (QPS) is the number of requests a system receives each second, and it is the usual unit for load. The average over a day is smaller than the peak at the busiest moment.
- Peak-to-average ratio
- The peak-to-average ratio is the busiest rate divided by the daily average rate. Systems are sized for the peak, so an estimate that stops at the average is too small by that factor.
Think of estimating how many piano tuners work in a city. Guess the number of pianos, then guess how many one tuner can serve in a year. No single guess is reliable. The errors partly cancel, and the answer lands in the right range. The analogy breaks when every guess leans the same way. Errors that agree multiply instead of cancelling, and the fourth step puts a number on that.
In one precise sentence, an estimate is a chain of multiplications over stated assumptions, rounded to one or two significant digits, often a power of ten. It is a skill of structure, not of memory: the same five moves work for storage, traffic, tokens or cost.
Step 1: State assumptions and round to simple numbers
Start by saying every input aloud, then round each to one or two digits so the arithmetic fits in your head. A service with 100 million daily users, each uploading half a photo a day, is 50 million photos a day. The numbers here are illustrative assumptions for a photo-sharing service, not data about any real one1.
Two rounding rules save time. A day has 86,400 seconds, which is rounded to 100,000; that is 15.7 percent too high, which is acceptable for an estimate1. Powers of two are rounded to powers of ten: the NIST binary prefixes define a kibibyte as 1,024 bytes against 1,000 for a kilobyte, and the gap grows from 2.4 percent at 2 to the power 10 to 10.0 percent at 2 to the power 401.
Step 2: Convert users and actions into requests per second
Divide a daily count by the seconds in a day to get an average rate, then multiply by a peak factor. With 50 million uploads a day, the average write rate is 578.7 per second, or 500 per second with the rounded day; with an assumed peak factor of 3 the design target is about 1,736 per second1. If each user also views 50 photos a day, the 5 billion views a day are 57,870 reads per second on average and 173,611 at peak1.
The read rate is 100 times the write rate here1, and that ratio, not the write rate, shapes the design: it argues for caching and for serving images from a content delivery network. Say the ratio aloud.
Step 3: Convert rates and counts into storage and bandwidth
Multiply a count by a size to get storage, and a rate by a size to get bandwidth. Bandwidth is the amount of data a link carries per second. Fifty million photos of 2 megabytes each is 100 terabytes a day. Kept for five years that is 182.5 petabytes, and with three copies of every photo, the replication factor, it is 547.5 petabytes1. If a storage node holds 100 terabytes, that is about 5,500 nodes.
For reads, 57,870 views a second at an assumed 200 kilobytes each is 11.57 gigabytes a second, or 92.6 gigabits a second on average1. Measured from one day of uploads, 1,825 days of retention and 3 copies multiply storage by 5,475, from 100 terabytes to 547.5 petabytes1. The peak factor multiplies traffic, not storage.
Step 4: Bound the error before you commit
Because every step multiplies, errors multiply too. Four factors that are each 20 percent too high make the answer 2.07 times too high, and four that are each 20 percent too low make it 0.41 of the truth1. At 10 percent each, the overshoot is 1.46 times. Nothing in the method removes this, so finish by saying how wrong you could be and which factor you trust least.
A useful habit is to compute a low case and a high case from the assumptions you are least sure of, and to check that the design decision does not change between them. If an answer of 5 petabytes or of 500 petabytes (illustrative) would lead to the same architecture, the precision does not matter. If it would not, say so and ask the interviewer to confirm the number that decides it.
Step 5: Check the result against the hardware
Compare the estimate with typical hardware speeds. Colin Scott's interactive table gives them by year, but it computes its values from trend formulas rather than measuring them, so treat them as a model. With its slider set to 2020, a main-memory reference takes 100 nanoseconds, a random read from a solid-state drive (SSD) 16 microseconds and a disk seek about 2.5 milliseconds (Scott, read 2026-10-24).
In the same model, reading 1 megabyte sequentially takes about 3 microseconds from memory, 49 from SSD and 825 from disk, so one terabyte takes 3 seconds, 49 seconds or 13.75 minutes1. A real drive is slower: the July 2020 data sheet for the Seagate Exos X18 gives a maximum sustained transfer rate of 270 megabytes a second, about 62 minutes per terabyte from one disk (Seagate data sheet, July 2020)1. The ordering holds: hot photos belong in memory or on SSD and the archive on disk. Quote hardware numbers as "about" with the year; Norvig's older list gives 250 microseconds per megabyte from memory and 20,000 from disk (Norvig).
Step-by-step description
- State inputs aloud and round them.
- Divide by seconds in a day; apply a peak factor.
- Multiply counts and rates by sizes.
- Give a low and a high case.
- Compare with memory, SSD and disk speeds.
- A day has 86,400 seconds, rounded to 100,000.
- Storage is count times size times retention times replication.
- Four factors each 20 percent too high make the answer 2.07 times too high.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
| Quantity | Illustrative value | How it is derived |
|---|---|---|
| Uploads per day | 50,000,000 | the assumed 100,000,000 daily audience times 0.5 |
| Average writes per second | 578.7 | uploads divided by 86,400 |
| Peak writes per second | 1,736 | average times a peak factor of 3 |
| Average reads per second | 57,870 | 5,000,000,000 views divided by 86,400 |
| New storage per day | 100 TB | 50,000,000 photos times 2 MB |
| Storage after 5 years | 182.5 PB | 100 TB times 365 times 5 |
| With 3 copies | 547.5 PB | 182.5 PB times 3 |
| Average egress | 92.6 Gbit/s | 57,870 views a second times 200 KB, times 8 bits per byte |
All inputs are assumptions chosen for the walkthrough, and every figure comes from the calculation script1. The estimate is only as good as those inputs, so it names them instead of hiding them.
Text description of the diagram
- Fifty million photos of 2 megabytes each is 100 terabytes a day.
- Kept for five years that is 182.5 petabytes, and with three copies of every photo it is 547.5 petabytes.
The hardware check is the second half of the example. In Scott's 2020 model, reading a terabyte at the per-megabyte times above takes 3 seconds from memory, 49 from SSD and 825 from disk; a single disk at its data-sheet rate takes about 62 minutes1.
Text description of the diagram
- Reading one terabyte takes 3 seconds from memory, 49 from SSD and 825 from disk.
- In the same model, reading one terabyte from disk takes 13.75 minutes; a single Seagate Exos X18 at its 270 MB/s data-sheet rate takes about 62 minutes.
Trade-offs and edge cases
The method trades precision for speed, and it fails in predictable ways. The ones to watch:
- Aligned errors. When all assumptions lean the same way the product is far off, as in step 4. Round some up and some down.
- Averages hide peaks. Sizing for the daily average under-provisions by the peak factor; some services have spikes far above 3 times, so ask.
- Stale hardware numbers. Latency tables are from a given year, so quote the year and use "about"; the interview loops guide shows where the estimate sits in a full round.
- Ignoring overhead. Replication, indexes, metadata and free space all enlarge storage; one factor in the example, three copies, already multiplies it by three.
- False precision. Reporting 578.7 writes a second implies accuracy the inputs do not have; say "about 600".
How to answer it in an interview
Estimate the storage and traffic for a photo-sharing service with 100 million daily users.
I will state assumptions and round. Say half a photo uploaded per user per day, so 50 million photos, at about 2 megabytes each, which is 100 terabytes a day. Over five years that is roughly 180 petabytes, and with three copies about 550. For traffic, 50 views per user is 5 billion views a day; dividing by about 100,000 seconds gives roughly 50,000 reads a second, so reads dominate writes by about 100 to 1, and I would design around caching. These are assumptions, so I would ask which one you want me to pin down, because errors multiply.
The spoken structure is: assume aloud, round on purpose, multiply, compare reads with writes, then name the weakest assumption.
Common mistakes
- "I need exact numbers first" (wrong). Estimation exists because you do not have them (right: state an assumption and move on).
- "86,400 must be used exactly" (wrong). Rounding to 100,000 costs 15.7 percent and saves the arithmetic (right: round and say so).
- "The average rate is the design target" (wrong). The system must survive the peak (right: multiply by a stated peak factor).
- "Storage is just daily volume" (wrong). Retention and replication multiply it by 5,475 in the example (right: include both).
- "One answer, no range" (wrong). Errors multiply, so a point estimate overstates confidence (right: give low and high cases).
Follow-up questions
What numbers should I memorise for a system design interview?
Memorise the shape, not the digits: memory is about a hundred nanoseconds, SSD tens of microseconds, a data-center round trip about half a millisecond, a disk seek a few milliseconds, and an ocean-crossing round trip about 150 milliseconds. These are values from Scott's 2020 model, so quote the year of the table you remember.
How accurate does a back-of-the-envelope estimate need to be?
Within a factor of ten is the goal, and within a factor of two is a good result. What matters is that the design decision stays the same across your low and high cases.
Why round 86,400 seconds a day to 100,000?
It makes division mental, and the error, 15.7 percent, is smaller than the uncertainty in the inputs. If an interviewer wants more precision, use 86,400.
How do I estimate storage for a service?
Count the items per day, multiply by the size of one, then by days of retention and by the replication factor. Add a note about metadata and indexes if they could matter. See design a distributed cache for a design where sizing drives the choices.
What if the peak factor is 10 instead of 3?
Multiply the average by the new factor and redo the comparison. With 578.7 average writes a second the peak becomes about 5,800 instead of about 1,700, and the 57,870 average reads reach about 580,000 at peak1. Say which factor you changed and whether the design still holds, which is the point of the low and high cases.
How do I turn an estimate into a number of servers?
Divide the peak rate or the stored size by what one machine can handle, then round up and add headroom. A node holding 100 terabytes gives about 5,500 nodes for 547.5 petabytes. The feature store design page shows the same arithmetic for machine learning data.
- Estimate by stating assumptions, rounding to powers of ten and multiplying.
- Divide daily counts by about 100,000 seconds, then multiply by a peak factor.
- Storage is count times size times retention times replication.
- Check the result against hardware latency, and quote the year of the table.
- Errors multiply: always give a low and a high case.
Sources
- Interactive Latencies (latency numbers every programmer should know, values by year) — Colin Scott (page undated; values shown for 2020; read 2026-10-24), 24 Oct 2026
- Teach Yourself Programming in Ten Years, 'Approximate timing for various operations on a typical PC' — Peter Norvig (page footer: copyright 2001-2014), 31 Dec 2014
- Exos X18 data sheet (max. sustained transfer rate 270 MB/s, outer diameter) — Seagate Technology (document DS2045.1-2007US, July 2020), 1 Jul 2020
- Prefixes for binary multiples — NIST, Reference on Constants, Units and Uncertainty (page undated; read 2026-10-24), 24 Oct 2026
