Back-of-the-Envelope Estimation

1The mental model (what this really is)#

Estimation is the bridge between "build Twitter" and "we need roughly 15 servers for the write path and a 300 GB cache." You are converting a product into physics: requests per second, bytes on disk, bits over the wire.

The three outputs that actually change a design.

• QPS (queries per second), split into read and write. Sizes your compute and tells you if reads dominate (they almost always do, often 100 to 1 for social or e-commerce reads versus writes).
• Storage, over a realistic window like 5 years. Tells you single box or sharded fleet. A single box tops out around a few TB before it gets painful; cross that and you are sharding.
• Bandwidth, bytes per second in and out. Surfaces the sneaky problems, like video or images blowing past everything else by 100x or more.

The discipline that signals seniority.

• Everything you estimate should feed one of those three outputs.
• If a number does not change a decision, do not compute it.
• A junior computes bytes per HTTP header. A senior computes the one number that decides single box versus fleet.

2Why it matters (the core idea)#

Interviewers use estimation to separate people who have operated real systems from people who have only read about them.

What one good sentence tells the room.

• Say "that's 50,000 writes per second, so a single Postgres box won't take it, we're sharding" and in one breath you have shown three things.
• You understand throughput limits.
• You know a single relational node realistically handles low tens of thousands of simple writes per second.
• You let data drive the design instead of reflex.

The deeper idea: decision-first estimation.

• Amateurs compute everything. Pros compute the one number that resolves the fork in front of them.
• Does this fit in memory? Do I need a CDN? Can one queue handle this?
• Each is a yes or no that a 30-second calculation answers.

It also keeps you honest.

• Caching feels free until you estimate the working set and realize it is 40 TB, which is hundreds of cache machines, not five.
• Fan-out-on-write feels clever until you compute that a celebrity with 50 million followers triggers 50 million writes per post, a 50 million row insert storm from a single tap.

3The template (how it works)#

Memorize these. This is the whole toolkit, and interviewers know you are supposed to have them cold. Fumbling 86,400 divided by anything on a whiteboard reads as unprepared.

Time, in round numbers:

• 1 day is about 86,400 seconds. I use 100,000 (10^5). It makes every division trivial and the error is under 20 percent, well inside our one-order-of-magnitude budget.
• 1 month is about 2.5 million seconds. 1 year is about 30 million.

Powers of two to data sizes (the "2^10 is a thousand" trick):

• 2^10 ≈ 1 thousand (KB)
• 2^20 ≈ 1 million (MB)
• 2^30 ≈ 1 billion (GB)
• 2^40 ≈ 1 trillion (TB)

Typical object sizes (ballpark, state your assumption):

• A short text record or tweet: ~300 bytes to 1 KB
• A user metadata row: ~1 KB
• A compressed photo: ~300 KB to 1 MB
• A minute of streamed video: ~5 to 15 MB depending on quality

Latency numbers that matter (orders of magnitude):

• Memory read: ~100 nanoseconds
• SSD random read: ~100 microseconds (1000x slower than RAM)
• Datacenter network round trip: ~500 microseconds
• Cross-continent round trip: ~100 milliseconds (so ~150 ms US to Europe)
• Disk (spinning) seek: ~10 milliseconds

The one takeaway from latency numbers.

• Memory is roughly a thousand times faster than SSD.
• A network hop across the world is a hundred thousand times slower than a local memory read.
• That is why we cache, and why we put data near users.
• If you only remember one row, remember RAM is ~100 ns and a cross-continent trip is ~100 ms, a billion-fold gap.

The procedure, every time:

1. Clarify scale. DAU? Actions per user per day? Read/write ratio?
2. Derive QPS. total_actions_per_day / 100,000 -> average QPS
 peak QPS = average * 2 to 3
3. Split read vs write. Usually reads >> writes (say 100:1 for social).
4. Size storage. bytes_per_object * objects_per_day * 365 * years
5. Size bandwidth. QPS * bytes_per_response (and the write side too)
6. State the decision. "This fits in RAM" / "we must shard" / "need a CDN"

Narrate every assumption before the number.

• Say it out loud: "Let's say 100 million daily active users, each reads their feed 10 times a day."
• Now the interviewer can correct you early, and your math is auditable.
• If they say "make it 10x," you change one input and re-run, instead of starting over.

4A worked example#

Let's size Twitter reads and storage. I'll narrate it the way I'd want to hear it in a room.

Scale. "I'll assume 300 million daily active users. Each user posts twice a day and reads their timeline 50 times a day. Reads dominate heavily, which is normal for social."

Write QPS.

tweets/day = 300M users * 2 = 600M writes/day
write QPS = 600M / 100,000 = 6,000 writes/sec
peak = ~15,000 writes/sec

• 6,000 average writes per second.
• A single well-tuned database might handle that, but at peak with replication and indexes, I'd shard the write path. Decision made.

Read QPS.

reads/day = 300M * 50 = 15B reads/day
read QPS = 15B / 100,000 = 150,000 reads/sec
peak = ~300,000 to 450,000 reads/sec

• 150,000 reads per second average means no single database.
• This screams heavy caching and read replicas. The read path is the whole game here.
• Note the ratio: 150,000 reads to 6,000 writes is 25 to 1, and at peak the read side is where everything breaks first.

Storage.

tweet size ~ 300 bytes (text) + metadata, call it 1 KB to be safe
per day = 600M tweets * 1 KB = 600 GB/day
per year = 600 GB * 365 ≈ 220 TB/year
5 years ≈ 1.1 PB

• About a petabyte over 5 years for tweet text alone. That is a sharded, distributed store, not one box.
• Note I used text only. Store media and you multiply by a lot, which is exactly why media goes to object storage plus a CDN, not the main database.
• Remember too that 3x replication is standard, so that 1.1 PB of data means provisioning ~3.3 PB of actual disk.

Cache sizing (the decision that matters). The key insight: we do not cache every tweet, we cache the hot ones. Say 20 percent of tweets drive 80 percent of reads, and we only need the last few days hot.

hot window = 2 days of tweets = 1.2B tweets
if we cache ~20% hot ≈ 240M tweets * 1 KB ≈ 240 GB

The conclusion I'd say out loud.

• "Reads are ~150K QPS versus ~6K writes, so this is a read-heavy system."
• "I'll put a cache in front holding roughly 240 GB of hot tweets, shard the write store across the petabyte of long-term data, and push media to a CDN."
• "The read path is where I'll spend design time."
• That is the payoff. Four small calculations, and the architecture picked itself.

Here is the flow those four numbers produce:

5Variations and gotchas#

Peak versus average.

• Traffic is not flat. A rough 2x to 3x multiplier on average QPS covers daily peaks.
• For spiky products (ticket sales, live sports, flash drops) it can be 10x or more, and you should say so.
• A concert on-sale that does 200,000 average QPS might hit 2 million for ninety seconds, and that spike is the only number that matters for capacity.

Fan-out is a trap.

• In social feeds, "write a tweet" can mean "write to N followers' feeds."
• Average fan-out might be 200, but a celebrity's is tens of millions. Always estimate the tail, not the mean, for fan-out.
• A star with 50 million followers posting is 50 million inserts for one tap.
• This is exactly where hybrid push and pull designs come from: push for normal users, pull (fan-out on read) for the handful of mega-accounts.

Read/write ratio drives everything.

• 100 to 1 read-heavy means cache and replicas.
• Write-heavy (logging, IoT, metrics) means you care about ingest throughput and partitioning, and caching barely helps because you rarely re-read a given data point.

Compression and encoding.

• Text compresses ~3 to 5x. JSON is fat.
• If storage is the deciding number, mention that real bytes on disk may be a third of the raw size, which can be the difference between a 1 PB and a 350 TB provisioning decision.

Replication multiplies storage.

• 3x replication is standard. If you computed 1 PB of data, you provision ~3 PB of disk.
• Easy to forget, and interviewers notice when you remember.

6Trade-offs the numbers expose#

Estimation is not the design, it is the lens that reveals the trade-offs. Here is how a single estimate forks the design each way:

The senior move: chain the number to a decision.

• "It's 50 TB, so it won't fit in memory, so we accept SSD latency, so I'll add a cache for the hot 5 percent."
• That chain, number to constraint to decision, is what they want to hear.

7Weak answer versus strong answer#

Same prompt, "design Twitter's timeline," same first two minutes. Watch the difference.

The gap is not intelligence.

• The strong answer treats estimation as the thing that produces the architecture.
• The weak answer treats the architecture as a list of components you name because you have heard of them.

The math is not homework before the design. The math is the design, out loud.

8Mistakes that cost people the round#

• Estimating things that change nothing. Spending five minutes on exact bytes per HTTP header while the interviewer waits. Compute only what forks the design.
• False precision. Writing 86,400 and doing long division. Use 10^5. Speed and clarity beat decimals, and fumbling arithmetic looks worse than rounding.
• Not stating assumptions. If you never say "I assume 10 reads per user per day," your QPS is unfalsifiable and nobody can help you. Narrate every assumption.
• Ignoring peak. Designing for average QPS and getting crushed at launch. Always name a peak multiplier: 2x to 3x normally, 10x for spiky products.
• Forgetting the read/write split. Treating all traffic as one blob. The split is usually the most important fact in the whole problem, because it decides whether caching even helps.
• Never using the number. Doing the math, then designing as if you hadn't. If the number did not change your next sentence, you estimated the wrong thing.

9Your practice path#

Do these in order. Time yourself. Each should take under 5 minutes once you're warm.

1. URL shortener. Writes per day, storage for N years, read/write ratio. Easy warm-up, teaches storage sizing. (Hint: writes are tiny, reads dominate, it all fits in cache.)
2. Twitter/newsfeed. QPS split, cache sizing, and fan-out. The canonical example from section 4.
3. Chat app (WhatsApp-style). Messages per day, storage growth, and concurrent connection count. Teaches you to estimate connections, not just requests. A billion users with persistent sockets is a very different sizing problem than request QPS.
4. Video platform (YouTube-style). Where bandwidth and storage dwarf QPS. Estimate TB per day of uploads and the egress bandwidth. You'll see why a CDN is non-negotiable: a few hundred thousand concurrent HD streams at ~5 Mbps each is terabits per second of egress.
5. Rate limiter / ad click aggregator. Write-heavy. Forces you to reason about ingest and partitioning instead of caching.

After each, write one sentence: "The deciding number was , so the design must ." If you can't finish that sentence, you estimated the wrong thing.

10Where this shows up#

Who expects it.

• Every company that runs a dedicated system design round: Google, Meta, Amazon, Microsoft, Uber, Netflix, Stripe, and essentially all senior and staff level loops at scaled startups.
• It usually appears in the first ten minutes of the design interview, right after requirements gathering, and again mid-interview when you justify a cache, a shard count, or a CDN.

How the hard rounds probe it.

• Bar-raiser and staff-level rounds push harder: they'll challenge an assumption ("what if it's 10x that?") to see if your design degrades gracefully or collapses.
• Having the numbers in your head means you can re-run the estimate live and adjust, which is exactly the composure they're testing for.
• The candidate who can say "at 10x, my 240 GB cache becomes 2.4 TB, still a dozen machines, so the shape holds" has already won that exchange.

See the company guides to find which rounds lean hardest on estimation and how each interviewer likes to see it.