System Design10 lessons20 quiz questions

Back-of-Envelope Estimation

Back-of-envelope estimation is the foundation of every system design interview. You will learn the numbers that every engineer carries in their head, the formulas that convert user activity into infrastructure requirements, and how to apply them to real systems. We start with raw benchmarks,...

What You Will Learn

  • Numbers Every Engineer Should Know
  • QPS Estimation
  • Storage Estimation
  • Bandwidth Estimation
  • Server Count Estimation
  • Database Sizing
  • Cache Sizing
  • Practice: Estimate for Twitter
  • Practice: Estimate for Uber
  • Practice: Estimate for YouTube

Overview

Back-of-envelope estimation is the foundation of every system design interview. You will learn the numbers that every engineer carries in their head, the formulas that convert user activity into infrastructure requirements, and how to apply them to real systems. We start with raw benchmarks, build up to full worked examples, and finish with three complete practice estimates for Twitter, Uber, and YouTube. Numbers Every Engineer Should Know The best system designers carry a mental lookup table of benchmark numbers. These are not trivia — they are the constants that let you convert any scale question into a concrete answer in seconds. Why Numbers Matter When an interviewer asks "how many servers do you need?", you cannot answer without knowing roughly how many requests a server can handle. When they ask "will this fit in memory?", you need to know how big a terabyte is. These numbers are the vocabulary of system design. The Power-of-Two Table All computer storage is measured in powers of Memorise these: The trick: each step up multiplies by roughly 1,So 1 TB is roughly 1,000 GB, which is roughly 1,000,000 MB. Latency Numbers These numbers come from Jeff Dean's famous talk at Google (2012), updated for modern hardware: Latency 0.5 ns 7 ns 100 ns 150 μs 10 ms 0.5 ms 150 ms Key insight: avoid disk I/O in the hot path. A single HDD seek is 100,000× slower than a RAM read. This is why caching exists. Throughput Benchmarks These are rough orders of magnitude for a single well-tuned instance: Throughput ~10,000 req/s per core PostgreSQL (simple read) ~5,000–10,000 QPS Redis (in-memory cache) ~1,000,000 msg/s per broker Cassandra (wide-column) Key insight: caches are 20× faster than databases. If your read QPS exceeds 5,000, you need a cache layer. Common Object Sizes Knowing typical sizes lets you estimate storage instantly: Size 1 byte UUID 8 bytes Average tweet 1 KB Compressed thumbnail 200 KB 1 minute of 720p video ~50 MB 1 minute of 4K video How to Use These in an Interview When you encounter an estimation problem: Write the relevant benchmarks in the corner of your whiteboard or doc Use them as constants in your formulas State them out loud: "I'm assuming a web server handles about 10,000 req/s" This signals that you know the numbers and that you're being transparent about your assumptions — both of which interviewers reward. Common Mistake Do not confuse MB/s (megabytes per second) with Mbps (megabits per second). Network bandwidth is usually quoted in bits; storage throughput in bytes. 1 Gbps network = 125 MB/s. Always check your units. Quick Drill Cover the right column and try to fill in each number from memory: L1 cache: RAM read: SSD read: Redis throughput: PostgreSQL throughput: ___ Repeat until instant recall. Java Implementation Python Implementation

Sample Quiz Questions

1. What is 2^30 in human-readable form?

Remember·Difficulty: 1/5

2. How many seconds are in a day (used in QPS estimation)?

Remember·Difficulty: 1/5

3. An app has 100M DAU and each user makes 10 requests per day. What is the average QPS?

Apply·Difficulty: 2/5

+ 17 more questions available in the full app.

Related Topics

Master Back-of-Envelope Estimation for Your Next Interview

Get access to full lessons, adaptive quizzes, cheat sheets, code playground, and progress tracking — completely free.