What Is Back-of-the-Envelope Estimation?
Back-of-the-envelope estimation is the practice of making quick, rough calculations to evaluate whether a system design is feasible. Rather than running precise benchmarks, you use known reference numbers, sensible assumptions, and simple arithmetic to arrive at order-of-magnitude answers. This skill is essential in system design interviews, where interviewers expect you to reason about scale, latency, and resource requirements on the spot.
The goal is never precision - it is directional correctness. If your estimate tells you a single database server can handle the load, you design differently than if the estimate says you need a distributed cluster. Getting comfortable with estimation means you can make informed architectural decisions quickly, both in interviews and in real engineering work.
Why Estimation Matters in System Design Interviews
System design interviews test your ability to think at scale. Interviewers want to see that you can translate vague requirements ("design a URL shortener") into concrete technical constraints. Back- of-the-envelope calculations close the distance between vague requirements and concrete constraints. They help you determine how many servers you need, whether data fits in memory, what your queries-per-second (QPS) target should be, and where bottlenecks will appear.
Without estimation, your designs are guesswork. With it, every architectural choice - from choosing a database to deciding on a caching strategy - is grounded in data. That is exactly the signal interviewers look for: structured, quantitative reasoning that drives design decisions.
Key Numbers to Memorise
Successful estimation starts with a set of reference numbers you can recall instantly. These fall into four categories:
- Latency: L1 cache ~1ns, L2 cache ~4ns, main memory ~100ns, SSD random read ~150µs, HDD seek ~10ms, same-data-centre round trip ~0.5ms, cross-continent round trip ~150ms.
- Throughput: A single modern server can handle roughly 10,000-50,000 concurrent TCP connections. A well-optimised web server can serve 1,000-10,000 requests per second. Sequential disk reads are ~100-200 MB/s on SSD.
- Storage: 1 character = 1 byte (ASCII) or 2-4 bytes (UTF-8), a typical tweet-sized message ~140 bytes, a high-resolution photo ~2-5 MB, one hour of HD video ~1-3 GB.
- Time conversions: 86,400 seconds in a day, ~2.5 million seconds in a month, ~31.5 million seconds in a year. Use these to convert daily active users into per-second rates.
How to Approach an Estimation Question
Follow a consistent framework for every estimation problem. First, clarify the scope - what exactly are you estimating (storage, bandwidth, QPS, number of servers)? Second, state your assumptions explicitly (daily active users, average actions per user, average payload size). Third, work through the arithmetic step by step, rounding aggressively to keep calculations manageable. Finally, sanity-check the result against what you know about real-world systems.
For example, to estimate the storage needed for a messaging service: start with 100 million daily active users, assume 40 messages per day at 100 bytes each, and you get 400 GB per day of raw message data. Add metadata (20% overhead), replication (3x), and you are looking at roughly 1.5 TB per day - about 550 TB per year. That tells you immediately that you need a distributed storage solution, likely with tiered hot and cold storage.
Common Estimation Patterns
Most estimation questions in system design scenarios follow a handful of patterns. QPS estimation starts with daily active users and works down to per-second rates. Storage estimation multiplies records by size and projects over time. Bandwidth estimation multiplies QPS by average response size. Memory estimation for caching uses the 80/20 rule - 20% of data typically accounts for 80% of requests, so cache that 20%.
Recognising which pattern applies is half the battle. Once you have the pattern, the arithmetic follows naturally. The interactive exercises above are designed to drill these exact patterns until they become second nature.
Frequently Asked Questions
- What are back-of-the-envelope calculations?
- Back-of-the-envelope calculations are rough estimations used to quickly assess the feasibility of a system design. The term comes from the idea of jotting down quick maths on the back of an envelope. In system design interviews, they help you reason about whether a proposed architecture can handle the expected load, how much storage you will need, and what kind of infrastructure is required - all without precise data.
- What numbers should I memorise for system design?
- You should memorise key latency numbers (L1 cache reference ~1ns, main memory reference ~100ns, SSD random read ~150µs, HDD seek ~10ms, round trip within a data centre ~0.5ms), throughput benchmarks (a single server can handle roughly 10,000-50,000 concurrent connections), storage units (1 MB = 1 million characters, 1 GB = 1 billion characters), and time conversions (86,400 seconds in a day, roughly 2.5 million seconds in a month). These reference points let you anchor your estimates.
- How do I estimate storage requirements?
- Start by estimating the number of records or objects you need to store, then multiply by the average size of each record. For example, if you are designing a messaging service with 100 million users sending an average of 40 messages per day, each message being roughly 100 bytes, you need about 400 GB of new message data per day. Then factor in metadata, indexes, replication (typically 3x), and a growth buffer. Always round up and use powers of 10 to keep the arithmetic simple.
- How accurate do my estimates need to be?
- In a system design interview, your estimates only need to be within an order of magnitude - that is, within a factor of 10. The interviewer is not looking for exact numbers. They want to see that you can reason logically, identify the right variables, make sensible assumptions, and use the result to inform your design decisions. Being off by 2x is perfectly fine; being off by 1000x suggests a fundamental misunderstanding.
- How do I practise estimation skills?
- The best way to practise is to estimate real-world systems regularly. Pick a service you use daily - YouTube, WhatsApp, Twitter - and estimate its storage, bandwidth, or compute requirements. Compare your estimates against published engineering blog posts. Use the interactive exercises above to drill specific scenarios. Over time you will build intuition for common patterns like calculating QPS from daily active users, or sizing a cache based on the working set.
Continue Your Interview Preparation
Back-of-the-envelope estimation is one piece of the system design puzzle. Combine it with the AI-powered interview preparation tool to practise full system design interviews, get feedback on your approach, and build the confidence to tackle any estimation question your interviewer throws at you.