Back-of-Envelope Estimation

Back-of-envelope estimation is the ability to quickly calculate whether a design will work at the required scale — before writing a single line of code.

Here's an analogy everyone understands. You're planning a road trip. Before you get in the car, you do some quick math: "It's 500 miles. My car gets 30 miles per gallon. Gas is $3.50 a gallon. So I need about 17 gallons, which costs roughly $60." You didn't calculate it to the penny. You didn't pull out a spreadsheet. You did napkin math — just enough to know whether the trip is affordable.

That's exactly what back-of-envelope estimation is in system design. Instead of miles and gallons, you estimate requests per secondHow many user actions (page loads, API calls, searches) hit your servers every second. Abbreviated QPS (queries per second). A busy website might handle 10,000-100,000 QPS., storage in terabytes, and bandwidthHow much data flows through your network per second, measured in Mbps or Gbps. Think of it as the width of a highway — more lanes means more cars (data) can travel at once. in gigabits per second. The goal isn't perfection — it's getting the right order of magnitudeThe power-of-10 "bucket" a number falls in. Is it 1GB or 1TB? That's a 1,000x difference. Getting the order of magnitude right (even if the exact number is off by 2-3x) is what matters in estimation.. Is the answer 1 gigabyte or 1 terabyte? That 1,000x difference changes your entire architecture.

Why does this matter? Three reasons, and they're all big.

In interviews, estimation shows you understand real-world scale. Anyone can say "use a database." Only someone who's done the math can say "we need ~18TB of storage per year, so we should plan for sharding from day one." That's the difference between a junior answer and a senior answer.

In production, estimation prevents disasters. Imagine deploying a system that needs 50TB of storage when you budgeted for 5TB. Or designing a single-server architecture for a feature that actually needs to handle 100,000 requests per second. These mistakes cost real money and real time — and 30 seconds of napkin math could have caught them.

In design reviews, estimation is the fastest sanity checkA quick, rough calculation to make sure your design isn't wildly off. You're not looking for the exact answer — you're checking that you're in the right ballpark. "Do we need 1 server or 1,000?" is a sanity check. you have. Before anyone writes a design document, before anyone provisions infrastructure, a 30-second calculation can tell you whether the approach is even in the right ballpark.

Picture this. You're in a system design interview. The interviewer says: "Design a URL shortener like bit.ly." You feel confident. You start talking about database schemas, load balancers, maybe even mention consistent hashing. The interviewer listens politely for two minutes, then interrupts:

You freeze. You have no idea. You were so busy designing the how that you never figured out the how much. And without "how much," your entire design is floating in the air with no foundation. Is one database enough or do you need ten? Should you cache aggressively or is the load light enough to skip it? You can't answer any of these questions without numbers.

Now picture a different candidate in the same interview. Same question — "Design a URL shortener." But this candidate starts differently:

That took 30 seconds. And it told the interviewer three things: this candidate understands scale, this candidate makes data-driven decisions, and this candidate won't accidentally design a system that falls over on day one. This candidate gets the offer.

Here's the key insight that changes everything about how you approach estimation:

Think about it this way. If you estimate 5,000 QPS and the real answer is 8,000 QPS, you're fine — both numbers suggest the same architecture (a few servers with a cache layer). But if you estimate 5,000 QPS and the real answer is 5,000,000 QPS, you're going to build something that collapses on launch day. Estimation doesn't need to be precise. It needs to land in the right order of magnitude.

Before you can estimate anything, you need some numbers burned into your brain. Not hundreds of numbers — just a handful. These are the "multiplication tables" of system design. Once they're automatic, estimation becomes as easy as mental arithmetic.

Let's start with the single most important reference table in all of system design: the powers of 2Because computers work in binary (base 2), all storage and memory sizes are powers of 2. A kilobyte is 2^10 bytes (1,024), a megabyte is 2^20 bytes (1,048,576), and so on. Knowing these lets you instantly convert between units.. Everything in computing — memory, storage, network packets — is measured in powers of 2. If you know five of them, you can estimate almost anything.

The pattern is beautiful in its simplicity: every 10 powers of 2, you jump by 1,000x. KB to MB is 2¹⁰. MB to GB is another 2¹⁰. GB to TB? Another 2¹⁰. So if someone says "we have 500 million records at 2KB each," you instantly know: 500M x 2KB = 1 billion KB = 1 million MB = 1,000 GB = 1 TB. Three hops up the ladder. That calculation should take you two seconds.

Now for the second set of numbers you need: time conversions. These come up in literally every estimation because you almost always start with "X per day" and need to convert to "Y per second" (since servers think in seconds, not days).

There are exactly 86,400 seconds in a day (60 x 60 x 24). That's annoyingly specific. For napkin math, we round it: 1 day ≈ 100,000 seconds (or 10⁵). It's only off by about 15%, which is nothing for estimation purposes. This single shortcut makes every daily-to-per-second conversion trivial.

A few more shortcuts that show up constantly:

Knowing how to do the math is only half the battle. You also need to know what to compare your numbers against. When your calculation says "I need 50,000 QPS," you need to instantly know: can one server handle that, or do I need fifty?

These are the benchmarksStandard performance measurements for common technologies. These aren't exact (they depend on hardware, configuration, query complexity, etc.), but they give you the right order of magnitude for estimation. that experienced engineers carry in their heads. They're not exact — a well-tuned PostgreSQL on beefy hardware might do 50K QPS, while a poorly indexed one on a micro instance might do 500. But for estimation, you don't need exact. You need the right order of magnitude.

Compute Benchmarks (QPS — Queries Per Second)

How much work can a single instance of each technology handle? These numbers assume reasonable hardware (4-8 cores, 16-32GB RAM) and typical workloads. The ranges reflect different query complexity — simple key lookups are fast, complex joins are slow.

Storage Benchmarks (How Big Is Everything?)

When you're estimating storage, you need to know how big typical pieces of data are. These sizes include reasonable metadata (timestamps, user IDs, etc.) — not just the raw content.

Network Benchmarks (How Fast Does Data Travel?)

Network speed affects how you design for latencyThe time it takes for a request to travel from the user to the server and back. Measured in milliseconds. A user in New York hitting a server in Virginia has ~10ms latency. Hitting a server in London? ~80ms. This is governed by the speed of light in fiber optic cable. (how fast users get a response) and throughputHow much total data you can push through the network per second. A 1 Gbps link can transfer about 125 MB/sec. If your system needs to serve 500 MB/sec of video, you need at least 4 Gbps of network capacity. (how much data you can move). The speed of light is a hard constraint — no amount of engineering can make New York to London faster than ~80ms round trip.

One conversion that trips people up: 1 Gbps = 125 MB/sec. That's because 1 byte = 8 bits, so you divide by 8. If your server has a 1 Gbps network link and needs to serve 500 MB/sec of video, you need at least 4 links (or a 10 Gbps connection). This is a common gotcha in bandwidth estimation.

Let's put these reference numbers to work with a quick example. Say you're designing a chat application and you estimate 10 million messages per day. Each message is about 1KB. How much storage per year? And can a single database handle the write load?

In 30 seconds, you went from "design a chat app" to "4TB/year, one DB handles writes, might need read replicas." That's the power of having reference numbers in your head. You didn't need a spreadsheet. You didn't need a calculator. You needed five numbers and basic arithmetic.

Every estimation you'll ever do in an interview or at work follows the same five steps. It doesn't matter whether you're estimating Twitter, YouTube, or a tiny startup app — the process is identical. Learn these five steps once, and you can estimate any system on the planet in under two minutes.

Think of it like a recipe. You wouldn't bake a cake by throwing random ingredients into an oven and hoping for the best. You follow steps: measure flour, add eggs, mix, bake. Estimation is the same — a fixed sequence of multiplications that always produces a useful answer.

Quick Example: Running All 5 Steps

Let's run through the entire framework with a simple app: 100K DAU, 10 actions per user per day, 2 KB per action. This could be a notes app, a to-do list, or a simple social feed. Watch how the five steps chain together — each one feeds the next.

See how fast that was? Five multiplications, and now you know exactly what infrastructure this app needs: one server, one database, done. No Kubernetes. No Redis. No microservices. The numbers told you the architecture should be dead simple — and that insight alone saves months of over-engineering.

Twitter (now X) is the classic example of a QPS-heavy estimation. The core question is: how many tweets are being written per second, and how many are being read per second? The gap between those two numbers reveals the entire architecture.

Before we touch any math, let's pin down our assumptions. In an interview, you'd say these out loud — the interviewer wants to hear you reason about what's realistic.

The Full Calculation Chain

What the Numbers Tell You About Architecture

The 10:1 read-to-write ratio is the single most important number from this estimation. It tells you that reads dominate everything. That one insight drives all of these architectural decisions:

• Caching is mandatory — with 93K reads/sec, you can't hit the database for every timeline request. A RedisAn in-memory data store used as a cache. Data lives in RAM instead of on disk, so reads are microseconds instead of milliseconds. Perfect for hot data that gets read millions of times. caching layer absorbs 95%+ of reads.
• Read replicas — even with caching, you need multiple database copies to handle cache misses. A primary database handles writes; read replicas handle the overflow.
• Fanout-on-write vs. fanout-on-read — when a user tweets, do you pre-compute every follower's timeline (write amplification) or compute it when each follower opens the app (read amplification)? At 10:1 read:write, pre-computing timelines at write time saves 10x the read-time work.
• CDN for media — at 3.7 Gbps egress, you absolutely need a CDNContent Delivery Network. A global network of servers that cache and serve content from locations close to users, reducing latency and offloading traffic from your origin servers. to distribute the load geographically.

YouTube is the storage and bandwidth monster of the internet. While Twitter deals mostly with tiny text blobs, YouTube deals with massive video files. The numbers here get staggering fast — and that's exactly why this is a great estimation exercise. It forces you to think about what happens when data sizes go from kilobytes to gigabytes.

Storage: The Upload Side

Let's start with what goes IN — how much raw video is YouTube receiving, and how much space does it take after processing?

Bandwidth: The Download Side

Storage is expensive, but egress bandwidth is where the real money goes. Every time someone watches a video, YouTube has to push that data to their device. With 800 million people watching 40 minutes a day, the numbers get wild.

The lesson from YouTube's estimation is clear: media changes everything. Text-based systems like Twitter need petabytes per year. Video-based systems like YouTube need petabytes per day. When you see "video" or "images" in a system design question, immediately multiply all your storage and bandwidth estimates by 100-1000x compared to text-only systems.

If there's one estimation that every system design candidate should have memorized, it's this one. The URL shortener (think bit.ly or tinyurl.com) is the single most common estimation question in interviews. Why? Because it's simple enough to do in 3-4 minutes, it covers all five estimation steps, and the numbers lead to interesting architecture decisions.

A URL shortener does one thing: you give it a long URL, and it gives you a short one. When someone clicks the short URL, it redirects them to the original long URL. That's it. But the scale of doing this billions of times reveals some surprising math.

Traffic

Storage

Can We Generate Enough Short Codes?

Here's where the estimation gets interesting. We need 182.5 billion unique short URLs over 5 years. Each short URL is 7 characters long, using Base62An encoding using 62 characters: lowercase a-z (26), uppercase A-Z (26), and digits 0-9 (10). Used for URL-safe short codes because all 62 characters are valid in URLs without encoding. encoding (a-z, A-Z, 0-9). How many possible codes is that?

Caching

At 116,000 reads per second, can we reduce the database load with a cache? Absolutely. The 80/20 ruleAlso called the Pareto principle. Roughly 80% of effects come from 20% of causes. For URLs: 80% of clicks go to just 20% of URLs. (Pareto principle) tells us that about 20% of URLs receive 80% of the traffic. If we cache just the popular ones:

WhatsApp is a mixed estimation — it combines QPS, storage, AND persistent connections. It's also the system where media vs. text reveals the most surprising insight: the text messages that everyone thinks of as "WhatsApp's data" are actually a rounding error compared to the photos and videos people send.

Message Traffic

Storage: Text vs. Media (The Surprise)

Here's where the estimation gets really interesting. Most people guess that text messages are WhatsApp's storage challenge. They're wrong — by a factor of a thousand. Let's do the math.

Persistent Connections

WhatsApp is a real-time messaging app. That means users don't poll the server asking "any new messages?" every few seconds — instead, each device maintains a persistent connectionA long-lived network connection (like a WebSocket) that stays open between the client and server. Instead of connecting fresh for every message, the phone keeps one connection open and receives messages instantly through it. to the server. Messages arrive instantly through this always-open channel. But maintaining millions of simultaneous connections requires its own infrastructure.

WhatsApp's estimation also reveals something about architecture: this is really two separate systems. The text/metadata system is a classic database problem (4 TB/day, 231K QPS — sharded database with replication). The media system is an object storage problem (5.2 PB/day — S3-like blob storage with CDN delivery). Most messaging apps split these into entirely different storage backends because the requirements are so different.

Every app sends push notifications — order updates, social activity, flash-sale alerts. It feels simple: fire off a message to a phone. But when 200 million users each get 5 pushes a day, you're suddenly dealing with a billion outbound API calls per day and the single hardest problem in notification systems: fan-outFan-out is when one event triggers many downstream actions. A single "flash sale starts" event might generate 200 million individual push notifications — that's extreme fan-out..

This example is different from the previous four because the bottleneck isn't storage or read QPS — it's outbound throughput to external APIs. You're at the mercy of Apple's APNs, Google's FCM, and browser Web Push servers, each with their own rate limits and latency profiles.

Assumptions

The Math

The Killer Scenario: Broadcast Fan-Out

The numbers above assume normal traffic — individual notifications for individual users. But what happens when marketing decides to send a "Flash Sale Starts NOW!" push to all 200 million users at once?

That single event becomes 200 million API calls to external push providers. Let's do the math on how long that takes depending on how many worker machines you throw at it:

With a single worker doing 10,000 API calls per second, it takes 5.5 hours to reach everyone. A "flash sale" notification arriving 5 hours late is worse than useless — it's embarrassing. Even 100 workers only get you down to 3 minutes. For truly instant broadcast, you need ~1,000 workers spun up temporarily — which is why notification systems use auto-scaling worker poolsA group of worker machines that automatically grows and shrinks based on queue depth. When a broadcast event floods the queue with 200M messages, the pool scales from 50 workers to 1,000+ within minutes, then scales back down when the queue is drained. behind a message queue.

Architecture Implications

The numbers tell us exactly what architecture to build:

• Message queue (Kafka or SQS) — You can't call 35,000 external APIs per second directly from your app servers. You need a buffer. The queue absorbs bursts (especially broadcast events) and lets workers drain at a sustainable rate.
• Separate queues per provider — APNs, FCM, and Web Push have different rate limits, different payload formats, and different retry behaviors. Separate queues let you tune each independently.
• Auto-scaling worker pool — Normal traffic needs ~50 workers. A broadcast event needs 1,000+. Static provisioning either wastes money (1,000 idle workers 99% of the time) or fails under load (50 workers trying to send 200M notifications). Auto-scaling solves both.
• Rate limiting per provider — Apple throttles APNs if you exceed their limits. Google throttles FCM. Your workers need token-bucket rate limiters per provider to avoid getting temporarily blocked.
• Delivery tracking as a separate pipeline — Don't block the send path waiting for delivery receipts. Fire-and-forget the notification, then process delivery callbacks asynchronously.

Even after you learn the 5-step method, there are traps that can silently destroy your estimates. Each one seems small — a forgotten multiplier here, a unit confusion there — but they compound. A 2× error in assumptions times an 8× unit confusion times a 3× missing replication factor = a 48× error in your final answer. That's the difference between "we need 10 servers" and "we need 480 servers." Let's walk through the seven traps and how to dodge each one.

You know the math now. But knowing math and performing it live — out loud, under pressure, with someone evaluating every word — are completely different skills. This section is your playbook: the exact script to follow, common questions interviewers ask, and the mental model of what the interviewer is actually scoring you on.

What the Interviewer Is Actually Scoring

Here's what most candidates don't realize: the interviewer does not care about your final number. They know it's an estimate. They know it'll be wrong. What they're scoring is your thinking process. Specifically, four things:

The 5-Step Script for Any Estimation Question

Memorize this sequence. It works for every estimation question, whether they ask about storage, bandwidth, servers, or cost. Each step takes about 10-15 seconds — the whole thing fits in 60 seconds.

Practice Question: Estimate Infrastructure for a Ride-Sharing App

Here's how a strong candidate thinks through this question in real time. Notice the structure: assumptions first, math second, implications third.

Common Interview Estimation Questions

Reading about estimation is like reading about push-ups — it doesn't make you stronger. The only way to get good at this is to do the math yourself. Set a 5-minute timer for each exercise. Don't peek at the hints until you've tried your own approach. The goal isn't to match the exact answer — it's to be within the right order of magnitudeWithin 10x of the real answer. If the answer is 5TB and you got 2TB or 15TB, you're fine. If you got 50GB or 500TB, something went wrong in your reasoning..

These exercises get progressively harder. Exercises 1-2 are warm-ups that practice the basic "users x activity x size" formula. Exercises 3-4 add complexity with replication, peak traffic, and write-heavy workloads. Exercises 5-6 are full system estimations that combine multiple dimensions — the kind you'll face in real interviews.

Keep these cards bookmarked. They're the numbers you'll reach for in every estimation — during interviews, capacity planning, or late-night "will this scale?" calculations. Each card is one fact you should know by heart.

Estimation gives you the numbers. The topics below teach you what to do with those numbers. When your estimate says "500K writes/sec," scalability tells you how to handle it. When it says "97% cache hit rate required," the caching page shows you how to achieve it. Every estimation answer points to an architecture decision — and these pages cover those decisions in depth.