How it works
Start with a decision, not a spreadsheet. Ask which estimate could change the architecture: peak writes, retained data, concurrent connections, or media bandwidth. Confirm the workload and retention requirements, and label any numbers you supply as assumptions.
Convert usage into rates. Daily events = daily active users × events per user per day; average events per second = daily events ÷ 86,400. For example, 100 million events per day is about 1,200 events/second on average. An assumed 5× peak gives roughly 6,000 events/second; scheduled bursts or flash sales may require a different model.
Estimate retained storage separately from throughput. Storage = events per day × stored bytes per event × retention days. At 100 million events/day and 200 bytes/event, that is 20 GB/day, or 600 GB over 30 days using decimal units. Three stored copies raise that to 1.8 TB before indexes, metadata, and operating headroom.
Estimate bandwidth at the relevant boundary. At 6,000 events/second and 200 bytes/event, incoming payload bandwidth is 1.2 MB/second, or 9.6 Mb/second. Protocol overhead, replication, and downstream consumers add traffic; fan-out can make outgoing bandwidth much larger than incoming bandwidth.
Distinguish request rate from concurrency. For a stable service, average in-flight requests ≈ throughput × average time in the system. At a steady 6,000 requests/second and 50 ms average response time, roughly 300 requests are in flight. Long-lived sockets need a separate estimate based on active sessions, connection memory, and heartbeat traffic.
Translate demand into capacity only when you have a credible per-node limit. Divide peak demand by measured sustainable capacity at the target latency, then account for failure reserve and other bottlenecks such as memory or disk bandwidth. If that capacity is unknown, present a conditional estimate and say what you would benchmark rather than inventing a universal requests-per-server number.
A worked example
Can a migration finish within a week?
Assume a migration must move 100 TB across a 1 Gb/second link. Using decimal units, the link carries at most 125 MB/second, so the ideal copy time is 100 trillion bytes ÷ 125 million bytes/second = 800,000 seconds, or about 9.3 days. The one-week deadline is already impossible on that link. If we assume only 70% of link capacity is usable for the copy, the estimate becomes about 13.2 days. Ongoing source writes also create change-capture traffic. I would propose more bandwidth or a longer migration window, then estimate whether change application can outpace new writes before cutover. I would also check source read and destination write limits; the network may not be the only bottleneck.
Trade-offs to say out loud
- Speed versus precision
- Rounded numbers keep the interview moving, but units and order of magnitude still need to be correct.
- Provisioning cost versus overload risk
- Peak capacity and failure reserve cost money, while sizing only for the average leaves the system exposed to predictable bursts.
- Simple averages versus uneven demand
- Fleet-wide totals can look manageable even when one tenant, partition, or popular item exceeds a single owner's capacity.
- Logical data versus physical footprint
- Replication, indexes, compaction space, and backups increase storage needs, while compression may reduce some components.
- Useful assumptions versus false confidence
- A clear range exposes uncertainty better than a precise result built on an unverified event size or peak multiplier.
When to reach for it
- The prompt gives user counts or daily activity, but you need request rates to reason about the read and write paths.
- Retention, event volume, or object sizes could determine whether storage fits on one node or needs partitioning.
- Video, photos, live updates, or group messaging make bandwidth and fan-out more important than API request counts.
- Persistent connections, worker concurrency, or cache contents may make memory the limiting resource.
- A migration deadline, queue backlog, or recovery target requires checking whether the available throughput can finish the work.
How to bring it up in the interview
- Lead with the architectural question: “I'll estimate peak ingestion and retained storage to see whether partitioning is necessary.” Skip calculations that cannot change a decision.
- State assumptions before multiplying, keep units beside each number, and round intermediate results rather than presenting unnecessary decimal places.
- Separate average demand, peak demand, and failure reserve. Expect the interviewer to ask what happens during a burst or when one node or availability zone is unavailable.
- Test the uncertain input that matters most: “If event size is 2 KB rather than 200 bytes, storage and bandwidth both increase tenfold.” Explain whether that changes your design.
- Close the loop with a conclusion and a validation plan. Interviewers may probe per-node benchmarks, cache misses, skew, fan-out, and whether recovery traffic competes with normal traffic.
Common mistakes
- Treating registered users as daily active users, or treating daily active users as simultaneous connections.
- Dividing daily traffic by 86,400 and provisioning for that average without considering bursts or regional concentration.
- Mixing bits and bytes, or switching silently between decimal GB and binary GiB.
- Counting only raw records while ignoring retention, replicas, indexes, fan-out, or retry traffic relevant to the decision.
- Declaring a server count from a memorized QPS limit, or spending several minutes on arithmetic without connecting the result to the architecture.
Where it comes up
Interview questions where back-of-the-envelope estimation is part of a strong answer, and why.
- Design a video streaming service like YouTubeConcurrent viewers, playback bitrates, and uploaded video volume determine delivery bandwidth, storage, and transcoding capacity.
- Design a metrics monitoring system like DatadogActive series, sampling intervals, and retention determine ingestion throughput and time-series storage requirements.
- Design a distributed cacheEntry sizes, metadata overhead, replication, and request skew determine memory capacity and whether hot keys exceed per-node limits.
- Design a chat app like WhatsAppConcurrent connections, message rates, and group fan-out determine connection-server memory and delivery capacity.
- Design a large data migration to the cloudDataset size, usable link bandwidth, and ongoing write volume determine whether bulk transfer and catch-up can meet the cutover deadline.
- Design a system to sort huge datasetsInput size, worker memory, and disk and network throughput determine external-sort passes and shuffle feasibility.
- Design a distributed tracing systemRequest volume, spans per request, sampling rate, and span size determine ingestion and retention costs.
- Design Facebook live commentsComment rate multiplied by audience size reveals the delivery bandwidth and fan-out capacity required for a hot stream.
Questions people ask
What is a back-of-the-envelope calculation in system design?
It is a rough calculation that connects workload assumptions to resource needs such as requests per second, storage, memory, or bandwidth. Its purpose is to guide an architectural decision, not produce an exact infrastructure bill.
What formulas should I know for system design estimation?
Useful formulas include average QPS = requests per day ÷ 86,400, retained storage = daily records × bytes per record × retention days, and payload bandwidth = messages per second × bytes per message. For a stable system, average concurrency ≈ throughput × average time in the system. Apply replication, fan-out, and overhead to the components they actually affect.
How much estimation should I do in a system design interview?
Do enough to resolve the major capacity questions, usually as a brief pass after clarifying requirements. Revisit estimates when a design choice introduces substantial fan-out, retained state, or recovery work. If an estimate will not affect a decision, explain why you are skipping it.