DEV Community

Cover image for Back-of-the-envelope estimation
Tech Paths
Tech Paths

Posted on • Originally published at techpaths.dev

Back-of-the-envelope estimation

#systemdesign #programming #webdev #computerscience

Originally published at TechPaths.dev

Back-of-the-envelope estimation means making quick, approximate calculations to understand the scale of a system — without a calculator, without exact data, and without spending more than 2-3 minutes.

In system design interviews, interviewers ask you to estimate because they want to see:

  • Do you know the key numbers?
  • Can you reason about scale?
  • Will your design actually handle the load?

The Numbers You Must Memorize

Powers of 2

Power Approximate value Name
2¹⁰ 1 thousand 1 KB
2²⁰ 1 million 1 MB
2³⁰ 1 billion 1 GB
2⁴⁰ 1 trillion 1 TB
2⁵⁰ 1 quadrillion 1 PB

Latency Numbers

Operation Latency
L1 cache read 1 ns
L2 cache read 4 ns
RAM read 100 ns
SSD read 100 µs
Network round trip (same DC) 500 µs
HDD read 10 ms
Network round trip (cross-region) 150 ms

Availability Numbers

Nines Downtime/year
99% 3.65 days
99.9% 8.7 hours
99.99% 52 minutes
99.999% 5 minutes

The Estimation Framework

Always follow this order:

  1. State assumptions — DAU and usage patterns
  2. Estimate traffic — RPS (reads and writes)
  3. Estimate storage — items × size × retention
  4. Estimate bandwidth — RPS × payload size
  5. Estimate servers — RPS ÷ capacity per server
  6. State result and sanity check

Step 1 — Traffic Estimation

Formula:

RPS = DAU × requests_per_user_per_day / 86400
Enter fullscreen mode Exit fullscreen mode

Example — Twitter-like system:

  • 300 million DAU
  • Each user reads 100 tweets/day, writes 1 tweet/day 
Read RPS  = 300M × 100 / 86400 ≈ 350,000 RPS
Write RPS = 300M × 1   / 86400 ≈ 3,500 RPS
Enter fullscreen mode Exit fullscreen mode

Rule of thumb: 80/20 rule — 80% reads, 20% writes for most social apps.

Step 2 — Storage Estimation

Formula:

Storage = items_per_day × item_size × retention_days
Enter fullscreen mode Exit fullscreen mode

Example — Twitter tweets:

  • 3,500 writes/second = ~300M tweets/day
  • Each tweet: 280 chars = ~300 bytes + metadata = ~1 KB
  • Keep 5 years = 1825 days 
Storage = 300M × 1KB × 1825 = 547 TB ≈ 0.5 PB over 5 years
Daily:   = 300M × 1KB        = 300 GB/day
Enter fullscreen mode Exit fullscreen mode

Step 3 — Bandwidth Estimation

Formula:

Bandwidth = RPS × average_payload_size
Enter fullscreen mode Exit fullscreen mode

Example — Twitter read bandwidth:

Read bandwidth = 350,000 RPS × 1KB = 350 GB/s
Enter fullscreen mode Exit fullscreen mode

That's why Twitter uses CDNs aggressively — serving 350 GB/s from origin servers would be impossible.

Step 4 — Server Estimation

Formula:

Servers needed = Total RPS / RPS per server
Enter fullscreen mode Exit fullscreen mode

A typical web server handles ~1,000-10,000 RPS depending on workload.

For 350,000 read RPS at 10,000 RPS/server:
Servers = 350,000 / 10,000 = 35 servers (minimum)
Enter fullscreen mode Exit fullscreen mode

Add 2-3x for redundancy and peak traffic → ~100 servers.

Common Estimation Examples

URL Shortener (like bit.ly)

Assumptions:

  • 100M DAU
  • 1 URL created per user per day
  • 100 reads per URL per day 
Write RPS = 100M / 86400 ≈ 1,200 RPS
Read RPS  = 1,200 × 100  = 120,000 RPS

URL size      = 100 bytes
Daily storage = 100M × 100B = 10 GB/day
Yearly        = 10 × 365    = 3.65 TB/year
Read-write ratio: 100:1
Enter fullscreen mode Exit fullscreen mode

Instagram Photo Storage 

Assumptions:
- 500M DAU
- 10% upload a photo daily = 50M photos/day
- Average photo size = 1 MB (after compression)

Daily storage  = 50M × 1MB  = 50 TB/day
Yearly storage = 50 × 365   = 18 PB/year
Enter fullscreen mode Exit fullscreen mode

Useful Approximations

Thing Approximate size
ASCII character 1 byte
Unicode character 2-4 bytes
Integer 4 bytes
Long/timestamp 8 bytes
UUID 16 bytes
Tweet (280 chars) ~300 bytes
Average webpage ~2 MB
Photo (compressed) ~300 KB - 1 MB
1 minute HD video ~100 MB
1 minute 4K video ~400 MB

How to Present in an Interview 

"Let me make some assumptions first:
 - 100M DAU
 - Read-heavy: 10:1 read-write ratio
 - Average payload: 1KB

Traffic:
 - Writes: 100M / 86400 ≈ 1,200 RPS
 - Reads:  1,200 × 10   = 12,000 RPS

Storage:
 - 1,200 writes/s × 1KB × 86400s = ~100 GB/day
 - Over 5 years: ~180 TB

This tells me I need:
 - Read replicas for the 10:1 read ratio
 - ~2 servers for writes, ~12 for reads
 - CDN for static content"
Enter fullscreen mode Exit fullscreen mode

Key Takeaways

  • Memorize: powers of 2, latency numbers, availability nines
  • Framework: Traffic → Storage → Bandwidth → Servers
  • Always state assumptions first — interviewers care about your reasoning, not exact numbers
  • Round aggressively: 86,400 ≈ 100,000
  • Sanity check: does the number feel right? PB for a major social network — yes. PB for a small blog — no.

Want more system design content? Check out TechPaths.dev — structured learning paths for system design, DSA, AI/ML, and cloud.

Top comments (0)