System Design: Mastering Back-of-the-Envelope Estimation

JamieCrafter Advanced 2h ago Updated Jul 25, 2026 43 views 1 likes 3 min read

Calculation errors rarely kill a system design interview; the real killer is calculating a number in silence, failing to defend it, and then never mentioning it again. When I'm reviewing technical specs with my team or prepping for architecture reviews, the goal isn't mathematical precision—it's identifying the binding constraint. If you can't tell whether your design is physically possible before you commit to it, you're just guessing.

The Logic of Capacity Estimation

Interviewers aren't testing your ability to do long division. They are looking for two specific engineering intuitions:
1. Can you identify which resource—storage, read throughput, write throughput, or bandwidth—is the actual bottleneck?
2. Do you understand how that bottleneck fundamentally alters the architecture?

If you calculate 30,000 reads/sec versus 200 writes/sec, you've just discovered a massive asymmetry. That discovery should dictate your entire strategy (e.g., leaning heavily into caching or pre-computation). If you calculate petabytes of storage and then move on without discussing sharding or archival, the math was a wasted exercise.

Aggressive Rounding and Mental Shortcuts

Precision is a distraction. In a real-world AI workflow or system deployment, you need the order of magnitude, not the fourth decimal place.

The most critical shortcut for any engineer is the "10^5 rule":

1 day = 86,400 seconds ≈ 10^5 seconds

Using $10^5$ introduces a roughly 16% error, but it makes mental division instant. No senior engineer will penalize you for this; they will, however, notice if you freeze for forty seconds trying to divide by 86,400.

Other essential benchmarks for a practical tutorial on estimation:

1 million requests/day ≈ 12/sec (round to 10 for speed)
1 KB × 1 million = 1 GB
1 KB × 1 billion = 1 TB
Peak traffic is typically 2–3× the average
Replicated storage is usually 3× the raw data size

A Linear Execution Path

To avoid getting lost in the numbers, always move in one direction:
Users → Requests → QPS → Storage → Bandwidth.

State every assumption explicitly. If you "smuggle" an assumption into your math without saying it, you risk building your entire design on a foundation the interviewer doesn't agree with.

Real-World Application: Social Feed Design

Let's apply this to a scenario: designing a social feed with 100M Daily Active Users (DAU).

Explicit Assumptions:

Post frequency: 0.2 posts/user/day
Feed reads: 10 reads/user/day
Average post size: 1 KB (including metadata)
Feed page size: 20 posts per load

Write Path Calculation:

# Total writes per day
100M users * 0.2 posts = 20M posts/day
# Average writes per second
20M / 10^5 = 200 writes/sec
# Peak write load (3x)
200 * 3 = 600 writes/sec

Read Path Calculation:

# Total reads per day
100M users * 10 reads = 1B feed loads/day
# Average reads per second
1B / 10^5 = 10,000 reads/sec
# Peak read load (3x)
10,000 * 3 = 30,000 reads/sec

Storage and Bandwidth:

# Daily storage
20M posts/day * 1 KB = 20 GB/day
# Yearly storage with 3x replication
20 GB * 365 * 3 = ~21 TB/year
# Peak egress bandwidth
30,000 reads/sec * 20 posts * 1 KB = 600 MB/s

Interpreting the Data

The value is in the conclusion, not the sum. A 50:1 read-to-write ratio is a massive signal. It tells you that you should perform the "heavy lifting" on the write path. Since writes are rare and reads are constant, you should fan out to precomputed feeds during the write process rather than assembling the feed on the fly during a read.

Furthermore, 21 TB/year is negligible for a modern cluster. This tells you that storage is not your binding constraint, so you shouldn't waste 15 minutes of the interview discussing complex sharding strategies. Your focus should be entirely on absorbing the read QPS.