Fundamentals/Basics

Back-of-Envelope Estimation

Basics

Visual Representation

Rendering diagram...

What is it?

🧮 Think of it like planning a wedding:

Before booking a venue, you estimate: "200 guests × ₹2000/plate = ₹4 lakh food budget. Need parking for 60 cars. Event is 5 hours." You don't need exact numbers — just ROUGH estimates to make decisions.

Back-of-envelope estimation in system design is the same: rough calculations to answer "can this work?" before building anything. How many servers do we need? How much storage? Can our database handle this load?

It's called "back of envelope" because you should be able to do it with a pen on the back of an envelope — no calculator needed. Just approximate numbers and simple math.

💡 Simple Summary: Quick, rough math to estimate if a system design is feasible — how much storage, bandwidth, and servers you'll need.

How it works — Like you're watching it happen

Example: Can Instagram store all uploaded photos?

  • Start with users — 2 billion total users. 500 million daily active users (DAU).
  • Estimate activity — Average user uploads 1 photo per week. Power users maybe 3/day. Let's say average across all DAU: 0.5 photos/day × 500M = 250 million photos/day.
  • Estimate size — Average photo after compression: 2MB. High-res: 5MB. Let's use 3MB average.
  • Calculate storage — 250M photos × 3MB = 750 TB per day. That's ~750 PB over 3 years!
  • Bandwidth — 250M photos × 3MB = 750 TB/day. Per second: 750 TB / 86400 = ~8.7 GB/s upload bandwidth just for photos.
  • Decision — We need massive distributed storage (not one server!), CDN for serving photos, and compression strategies.

    • See? No code, no exact numbers — just enough math to make architectural decisions.

    ❓ But wait — these numbers are just guesses. How can we make decisions from guesses?

    The goal isn't precision — it's ORDER OF MAGNITUDE. Whether it's 200 million or 300 million photos/day doesn't change the architecture. But the difference between 1 million and 200 million is HUGE (one server vs hundreds). Even rough estimates help you determine: "do I need 1 server or 1000? Do I need 1 GB storage or 1 PB?" That's what matters for architecture decisions.

    Why should you care? (Interview perspective)

  • 🎯 Interviewers EXPECT you to do this in the first 5 minutes of a system design interview
  • Shows you can think about SCALE before jumping into code
  • Helps you justify decisions: "Based on 50K requests/sec, we need approximately 10 servers"
  • Demonstrates practical engineering thinking, not just theoretical knowledge

    • Key Things to Remember

  • Key numbers to memorize:

    • - 1 day = 86,400 seconds ≈ ~100K seconds (use 100K for easy math)

    - 1 million requests/day ≈ 12 requests/second

    - 1 billion requests/day ≈ 12,000 requests/second

    - 1 KB = text message. 1 MB = photo. 1 GB = movie. 1 TB = 1000 movies. 1 PB = 1000 TB.

    - Average web request: 1-10 KB. Image: 1-5 MB. Video minute: 50-100 MB.

  • Round aggressively — Use powers of 10. 86,400 ≈ 100,000. It's close enough.
  • Start with DAU — Daily Active Users is your starting point for almost all estimations.
  • Peak vs Average — Peak traffic is usually 2-5x average. Design for peak, not average.
  • Read:Write ratio — Most apps are read-heavy. Instagram: 100 reads per 1 write. This affects caching and database design.
  • The 80/20 rule — 80% of traffic goes to 20% of data (hot data). Cache accordingly.
  • QPS (Queries Per Second) — The universal metric. "How many queries/second must the DB handle?"
  • Storage growth — "How much data per day × retention period." If you keep data for 5 years, multiply daily by 1825.
  • Server capacity — One modern server: ~10K-50K simple requests/sec. Complex queries: 1K-5K/sec. Use these as baselines.
  • Network — 1 Gbps link ≈ 125 MB/sec. A typical data center has 10-100 Gbps links.

    • Real Examples You Use Daily

    🐦 Twitter/X estimation: — 500M tweets/day. Each tweet: ~1 KB text + metadata. Storage: 500 GB/day new data. That's ~180 TB/year just for tweets. Reads: 500M users × 200 tweet views/day = 100 BILLION read requests/day ≈ 1.2M reads/sec. Clearly needs heavy caching!

    📺 Netflix bandwidth — 200M subscribers, maybe 50M watching simultaneously. 4K stream = 25 Mbps. 50M × 25 Mbps = 1.25 Petabits/sec. Obviously one server can't do this — need thousands of CDN nodes worldwide.

    💬 WhatsApp messages — 100 billion messages/day (real number). That's 1.15 million messages per second. Each message ~1 KB. Storage: 100 TB/day. This tells you: need massive write throughput, probably noSQL database, heavy sharding.

    🚗 Uber location updates — 5M active drivers sending location every 4 seconds. That's 5M/4 = 1.25M writes/second. Each update: 50 bytes (lat, long, timestamp). 1.25M × 50 = 62.5 MB/sec = manageable bandwidth, but extreme write QPS.

    Common Mistakes in Interviews

    ❌ Being too precise — Don't say "23,148,148 requests per second." Say "about 23 million" or "roughly 20M." Precision suggests you're missing the point — it's about order of magnitude.

    ❌ Forgetting peak load — You calculate average of 10K requests/sec. But at midnight on New Year (for a messaging app) it might be 100K/sec. Always mention peak = 3-5x average.

    ❌ Not stating assumptions — "I'm assuming 30% of registered users are daily active" — say this out loud! Interviewers want to see your THINKING process, not just final numbers.

    ❌ Skipping this step entirely — Some candidates jump straight to drawing boxes. Spending 3-5 minutes on estimation FIRST shows structured thinking and helps you make better design choices.

    ❌ Not connecting estimates to decisions — "We'll have 50K requests/sec. Moving on..." NO! Say "With 50K requests/sec, a single server can't handle this, so we need at least 10 servers behind a load balancer and caching layer to absorb read traffic."

    🎯 Interview One-Liner

    "I'd estimate our system needs to handle approximately X requests per second based on Y daily active users, which means we need N servers for compute and Z terabytes of storage growing at W per month — let me walk you through the math."

    Interview Q&A

    Q: Walk me through estimating storage for a URL shortener.

    Assumptions: 100M new URLs/month (writes). Each URL mapping: short code (7 bytes) + original URL (avg 100 bytes) + metadata (50 bytes) = ~150 bytes. Monthly: 100M × 150B = 15 GB/month. Over 5 years: 15 GB × 60 = 900 GB ≈ 1 TB. One server can hold this easily! But reads matter more: if 100:1 read-write ratio, that's 10 BILLION redirects/month = ~4000 reads/sec. Need caching (hot URLs in Redis).

    Q: How many servers does a chat app with 10M DAU need?

    10M DAU, each sends 40 messages/day. That's 400M messages/day = ~4600 messages/sec writes. Each server handles ~5000 writes/sec (with DB). So ~1-2 servers for writes. But 10M users need persistent WebSocket connections: one server handles ~50K connections. So 10M / 50K = 200 servers just for connections! Connections, not throughput, are the bottleneck here.

    Q: How do you estimate bandwidth for a video streaming service?

    10M concurrent viewers. Quality mix: 50% at 1080p (5 Mbps), 30% at 720p (3 Mbps), 20% at 4K (25 Mbps). Average per user: 0.5×5 + 0.3×3 + 0.2×25 = 2.5 + 0.9 + 5 = 8.4 Mbps. Total: 10M × 8.4 = 84 Tbps. You can't serve this from one location! Need CDNs with ~1000+ edge servers worldwide, each serving a local audience.

    Q: What's the 80/20 rule and how does it affect your design?

    80% of requests hit 20% of data (Pareto principle). For a social media app: 20% of posts (trending/viral content) generate 80% of views. Design implication: cache the hot 20% in memory (Redis). If total data is 10 TB but hot data is 2 TB, you need 2 TB of Redis — expensive but dramatically reduces DB load for 80% of requests.

    Q: How do you handle estimation when you don't know the exact numbers?

    State reasonable assumptions and ask the interviewer: "I'll assume 50M DAU with 10 requests per user per day — does that sound reasonable for this product?" The interviewer will adjust if needed. The key is: show your METHODOLOGY. Even if your assumptions are off, the calculation approach should be sound.

    Quick Quiz

    1/5

    You have 10 million daily active users, each making 20 requests per day. Approximately how many requests per second is that?

    Single Point of Failure (SPOF)Content Delivery Networks (CDN)