What are BackoftheEnvelope Estimations

Back of the envelope estimations in system design interviews are like quick, rough calculations you might do on a napkin during lunch - they're not detailed or exact, but give you a good ballpark figure. These rough calculations help you quickly assess the feasibility of a proposed solution, estimate its performance, and identify potential bottlenecks.

Purpose

Back-of-the-envelope estimation is a technique used to quickly approximate values and make rough calculations using simple arithmetic and basic assumptions. This method is particularly useful in system design interviews, where interviewers expect candidates to make informed decisions and trade-offs based on rough estimates.

Why is Estimation Important in System Design Interviews?

During a system design interview, you’ll be asked to design a scalable and reliable system based on a set of requirements. Your ability to make quick estimations is essential for several reasons:

1. Indicates System Scalability: Highlights your understanding of how the system can grow or adapt.
2. Validate proposed solutions: Estimation helps you ensure that your proposed architecture meets the requirements and can handle the expected load.
3. Identify bottlenecks: Quick calculations help you identify potential performance bottlenecks and make necessary adjustments to your design.
4. Demonstrate your thought process: Estimation showcases your ability to make informed decisions and trade-offs based on a set of assumptions and constraints.
5. Communicate effectively: Providing estimates helps you effectively communicate your design choices and their implications to the interviewer.
6. Quick Decision Making: Reflects your ability to make swift estimations to guide your design decisions.

Estimation Techniques

1. Rule of thumb

Rules of thumb are general guidelines or principles that can be applied to make quick and reasonably accurate estimations. They are based on experience and observation, and while not always precise, they can provide valuable insights in the absence of detailed information. For example, estimating that a user will generate 1 MB of data per day on a social media platform can serve as a starting point for capacity planning.

2. Approximation

Approximation involves simplifying complex calculations by rounding numbers or using easier-to-compute values. This technique can help derive rough estimates quickly and with minimal effort. For instance, assuming 1,000 users instead of 1,024 when estimating storage requirements can simplify calculations and still provide a reasonable approximation.

3. Breakdown and aggregation

Breaking down a problem into smaller components and estimating each separately can make it easier to derive an overall estimate. This technique involves identifying the key components of a system, estimating their individual requirements, and then aggregating these estimates to determine the total system requirements. For example, estimating the storage needs for user data, multimedia content, and metadata separately can help in determining the overall storage requirements of a social media platform.

4. Sanity check

A sanity check is a quick evaluation of an estimate to ensure its plausibility and reasonableness. This step helps identify potential errors or oversights in the estimation process and can lead to more accurate and reliable results. For example, comparing the estimated storage requirements for a messaging service with the actual storage used by a similar existing service can help validate the estimate.

Types of Estimations in System Design Interviews

In system design interviews, there are several types of estimations you may need to make:

1. Load estimation: Predict the expected number of requests per second, data volume, or user traffic for the system.
2. Storage estimation: Estimate the amount of storage required to handle the data generated by the system.
3. Bandwidth estimation: Determine the network bandwidth needed to support the expected traffic and data transfer.
4. Latency estimation: Predict the response time and latency of the system based on its architecture and components.
5. Resource estimation: Estimate the number of servers, CPUs, or memory required to handle the load and maintain desired performance levels.

Process

1. Understand the Scope: Clarify the scale of the problem - how many users, how much data, etc.
2. Use Simple Math: Utilize basic arithmetic to estimate the scale of data and resources.
3. Round Numbers for Simplicity: Use round numbers to make calculations easier and faster.
4. Be Logical and Reasonable: Ensure your estimations make sense given the context of the problem.

Practical Examples

1. Load Estimation

Suppose you’re asked to design a social media platform with 100 million daily active users (DAU) and an average of 10 posts per user per day. To estimate the load, you’d calculate the total number of posts generated daily:

100 million DAU * 10 posts/user = 1 billion posts/day

Then, you can estimate the request rate per second:

1 billion posts/day / 86,400 seconds/day ≈ 11,574 requests/second

2. Storage Estimation

Consider a photo-sharing app with 500 million users and an average of 2 photos uploaded per user per day. Each photo has an average size of 2 MB. To estimate the storage required for one day’s worth of photos, you’d calculate:

500 million users * 2 photos/user * 2 MB/photo = 2,000,000,000 MB/day

Convert it or it’s useless: 2,000,000,000 MB is ≈ 2 PB per day. That figure forces the decision — no single cluster ingests 2 PB/day into a B-tree, so you need object storage with erasure coding, a dedicated upload pipeline, and lifecycle tiering (hot → warm → cold) from day one.

3. Bandwidth Estimation

For a video streaming service with 10 million users streaming 1080p videos at 4 Mbps, you can estimate the required bandwidth:

10 million users * 4 Mbps = 40,000,000 Mbps

Again, convert: 40,000,000 Mbps is ≈ 40 Tbps of aggregate egress — orders of magnitude beyond what a single datacenter can economically push. The number forces a CDN serving the vast majority (>90%) of bytes from edge caches, with the origin sized only for cache-fill traffic.

4. Latency Estimation

Suppose you’re designing an API that fetches data from multiple sources, and you know that the average latency for each source is 50 ms, 100 ms, and 200 ms, respectively. If the data fetching process is sequential, you can estimate the total latency as follows:

50 ms + 100 ms + 200 ms = 350 ms

If the data fetching process is parallel, the total latency would be the maximum latency among the sources:

max(50 ms, 100 ms, 200 ms) = 200 ms

5. Resource Estimation

Imagine you’re designing a web application that receives 10,000 requests per second, with each request requiring 10 ms of CPU time. To estimate the number of CPU cores needed, you can calculate the total CPU time per second:

10,000 requests/second * 10 ms/request = 100,000 ms/second

Assuming each CPU core can handle 1,000 ms of processing per second, the number of cores required would be:

100,000 ms/second / 1,000 ms/core = 100 cores

The same example also gives you concurrency, not just core count, via Little's Law: the number of requests in flight at once is L = λ × W (arrival rate × average time in the system). Here L = 10,000 req/s × 0.01 s = 100 concurrent requests — which is exactly why ~100 cores (or ~100 pooled DB connections, or a thread pool sized near 100) is the floor. Throughput tells you how many you finish per second; Little's Law tells you how many are open simultaneously, and that second number is what sizes pools, connection limits, and memory-per-request.

Latency numbers every programmer should know

These order-of-magnitude figures come from the widely circulated "Latency Numbers Every Programmer Should Know" (originally by Jeff Dean / Peter Norvig). Use them for relative scale and design intuition, not as exact benchmarking values.

These are 2009-era spinning-disk and 1 Gbps figures — on modern NVMe SSDs a sequential 1 MB read takes ~1 ms and a random read ~100 µs (see the SSD row in the anchors table below), and 10–100 Gbps networks move 1 MB in well under a millisecond. The relative ordering — cache ≪ RAM ≪ network ≪ disk ≪ cross-continent WAN — is what to memorize; that ordering, not the exact values, is what drives design decisions.

From estimate to architecture

Estimates become useful only when they force a design decision. Below is a concrete example: a URL shortener handling 100 million new URLs per day with a 100:1 read-to-write ratio.

Quantity	Estimate	Decision it forces
New writes/s	100M / 86,400 ≈ 1,160/s	Tiny immutable records → a sharded key-value store; no relational joins needed.
Reads/s	1,160 × 100 ≈ 116,000/s	Read-heavy traffic → add a Redis/Memcached cache in front of the DB.
Storage (5 years)	~500 bytes/URL × 100M/day × 365 × 5 ≈ 91 TB	Too much for one node → partition by short-key hash; consider archive tier.
Peak vs average	Peak ≈ 3× average → ~350K reads/s at peak	Provision cache and DB capacity for peak; use auto-scaling for transient bursts.

The same numbers also tell you what not to do: a single SQL database cannot absorb 350K reads/s, and storing 91 TB of tiny records in one B-tree is a maintenance nightmare. Estimation is the bridge between "sounds reasonable" and "this specific architecture is justified."

System Design Examples

1. Designing a messaging service

For a WhatsApp-like service, don’t list what you would estimate — estimate it:

2 billion users × 40 messages/user/day = 80 billion messages/day
80 billion / 86,400 s ≈ 926,000 messages/second average
80 billion × 100 bytes/message ≈ 8 TB/day of text

~926K messages/s average (2–3M at peak) rules out any single ingestion point — it forces a partitioned message queue and horizontally sharded storage. The 8 TB/day of text is modest; media attachments, which dwarf text by orders of magnitude, are what actually drive the storage design.

2. Designing a video streaming platform

For a Netflix-like service:

200 million subscribers × 10% concurrent at peak = 20 million streams
20 million streams × 5 Mbps = 100 Tbps peak egress

100 Tbps cannot come out of origin datacenters — the number makes a CDN mandatory, serving essentially all video bytes from edge caches, with the origin handling only catalog metadata and cache-fill.

Tips for Successful Estimation in Interviews

Estimation plays a crucial role in system design interviews, as it helps you make informed decisions about your design and demonstrates your understanding of the various factors that impact the performance and scalability of a system. Here are some tips to help you ace the estimation part of your interviews:

1. Break down the problem

When faced with a complex system design problem, break it down into smaller, more manageable components. This will make it easier to estimate each component’s requirements and help you understand how they interact with each other. By identifying the key components and estimating their requirements separately, you can then aggregate your estimates to get a comprehensive view of the system’s needs.

2. Use reasonable assumptions

During an interview, you may not have all the necessary information to make precise estimations. In such cases, make reasonable assumptions based on your knowledge of similar systems, industry standards, or user behavior patterns. Clearly state your assumptions to the interviewer, as this demonstrates your thought process and enables them to provide feedback or correct your assumptions if necessary.

3. Leverage your experience

Drawing from your past experiences can be beneficial when estimating system requirements. If you have worked on similar systems or have experience with certain technologies, use that knowledge to inform your estimations. This will not only help you make more accurate estimations but also showcase your expertise to the interviewer.

4. Be prepared to adjust your estimations

As you progress through the interview, the interviewer may provide additional information or challenge your assumptions, requiring you to adjust your estimations. Be prepared to adapt and revise your estimations accordingly. This demonstrates your ability to think critically and shows that you can handle changing requirements in a real-world scenario.

5. Don’t Forget to Ask Clarifying Questions

Don’t hesitate to ask the interviewer clarifying questions if you’re unsure about a requirement or assumption. This will help you avoid making incorrect estimations and showcase your problem-solving abilities.

6. Communicate your thought process

Throughout the estimation process, communicate your thought process clearly to the interviewer. Explain how you arrived at your estimations and the assumptions you made along the way. This allows the interviewer to understand your reasoning, provide feedback, and assess your problem-solving skills.

Worked estimation: Twitter QPS and storage

Let’s close the loop on a canonical problem — a Twitter-like service with 300 million daily active users (DAU) and an average of 5 tweets per user per day.

Quantity	Calculation	Result
Tweets per day	300M DAU × 5 tweets	1.5B tweets/day
Average write QPS	1.5B / 86,400	~17,400 tweets/s
Peak write QPS	3× average	~52,000 tweets/s
Read:write ratio	Assume 100:1	~1.74M reads/s average, ~5.2M peak
Tweet storage	280 bytes metadata + 140 bytes text	~420 bytes/tweet
Daily storage	1.5B × 420 bytes	~630 GB/day
5-year storage	630 GB × 365 × 5	~1.15 PB

What these numbers force: a single database cannot absorb 5.2M reads/s, so you need a cache and fan-out architecture. A single node cannot hold 1.15 PB, so you need partitioning. And 52K writes/s sustained means your ID generator and ingestion pipeline must be horizontally scalable.

Common anchors table

These anchors keep you from inventing numbers in an interview. State them explicitly, then adjust if the interviewer disagrees.

Anchor	Conservative value	Notes
Seconds per day	86,400	Use 100,000 for mental math if the interviewer accepts it.
Peak vs average	2–3×	Higher for event-driven traffic (launches, sports).
Average tweet / short post	~300 bytes metadata + text	Media excluded; count media separately.
Photo	1–5 MB	Depends on compression and resolution.
1 minute of video	10–50 MB	Streaming bitrate dominates.
1 modern server QPS	1K–10K	Varies wildly by workload; use as a sanity check.
1 SSD random read	~0.1 ms	Still far slower than memory.
Same-datacenter RTT	0.5 ms	Add queueing and processing on top.
Cross-continent RTT	100–150 ms	Speed-of-light floor; unavoidable.

Order-of-magnitude sanity-check drill

After you produce an estimate, ask these three questions before moving on:

1. Does the daily volume fit on one machine? If your answer is more than a few terabytes per day, the answer is no — design for partitioning.
2. Does the peak QPS fit through one network link? A 10 Gbps link gives you roughly 1 GByte/s. If your bandwidth estimate exceeds that, you need fan-out or geographic distribution.
3. Does the read traffic fit in memory? If your working set is small (e.g., user sessions) but your read QPS is high, caching is the obvious win. If the working set is huge (e.g., all historical tweets), caching only helps the hot tail.

Example sanity check for Twitter: 1.15 PB over five years will not fit in RAM, so you partition by time or user. 5.2M reads/s will not hit one database, so you cache and fan-out. 630 GB/day of tweets will not break a modest object-store ingestion pipeline, but 52K writes/s sustained will stress your ID generator.

Pitfalls and defending your estimate

Two failure modes sink estimation rounds. The first is over-architecting ahead of the numbers: reaching for a multi-region message mesh or global sharding when the arithmetic says 2,000 QPS and a single primary with a read replica would comfortably serve it. Let the estimate justify the machinery — never the reverse. The second is false precision: quoting "7,342.19 requests/second" invites a challenge you cannot defend and signals you have mistaken the exercise. Estimation is an order-of-magnitude tool; round aggressively and say so out loud. A related trap is the unit slip — mixing bits and bytes (a 1 Gbps link carries ~125 MB/s, not 1 GB/s) or per-day and per-second — which quietly moves an answer by an order of magnitude and invalidates every gate downstream.

Expect the interviewer to push on your assumptions. Three drills recur almost every round:

• "Why size for peak instead of average?" Capacity provisioned at the average silently drops requests during the evening spike or a launch event; you size the serving tier for peak (here 2–3× average) and let cheaper, elastic tiers absorb the rest.
• "Your peak factor is 3× — defend it." State it as an assumption tied to the traffic shape: diurnal social traffic ≈ 2–3×, while event-driven traffic (sports, ticket on-sales) can spike 10×+. Note that because architecture gates flip at roughly 10× boundaries, a 2× vs 3× disagreement rarely changes the design — so it is not worth arguing.
• "Which numbers actually changed your architecture?" Point at the gates: QPS decides shard-vs-single-node and whether a cache is mandatory; total storage decides the datastore family; egress bandwidth decides whether a CDN is unavoidable. Any number that does not move a gate is just color — recompute aloud, restate the assumption, and move on.

Conclusion

Back-of-the-envelope estimations are crucial in system design interviews as they showcase your ability to grasp the scale of a system quickly and assess the feasibility and resource needs of your design. It's a skill that demonstrates both technical knowledge and practical problem-solving ability.

I just read a lesson on **What are BackoftheEnvelope Estimations** (System Design) and want to truly understand it. Explain What are BackoftheEnvelope Estimations from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **What are BackoftheEnvelope Estimations** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **What are BackoftheEnvelope Estimations** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **What are BackoftheEnvelope Estimations** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.