In Progress

Track 1: Core Foundations, Frameworks & Networkingbeginner⏱️ 15 min read

Module 1.3 · Engineering Arithmetic

Capacity Estimation &
Back-of-the-Envelope Math

Every high-level system design interview begins with a simple question: "How big does this need to be?" Learn the 5 first-principles formulas that allow senior architects to size traffic, disk, RAM, and network pipes in 30 seconds on a whiteboard without a calculator.

Section 01 · The Mental Paradigm

The "Grocery Store" Ballpark Principle

When you walk down the supermarket aisles tossing items into your cart, you don't calculate to the exact penny ($3.49 + $7.89 + $12.19). You round to the nearest dollar ($3 + $8 + $12 = $23) to know if you have enough money before reaching the checkout.

❌ The Junior Trap: Decimal PerfectionSLOW

Trying to do exact long division with pen and paper: "500,000,000 divided by 86,400 equals 5,787.037..." This burns 15 minutes of interview time, causes arithmetic stress, and distracts from core architecture.

✅ The Senior Architect: Ballpark Orders of MagnitudeCONFIDENT

Rounding numbers to powers of 10: "86,400 is roughly 100k. 500M divided by 100k is roughly 5,000 QPS. At 2× peak rush hour, we design for 10k QPS." Done in 10 seconds, leaving 40 minutes for deep system trade-offs!

Why Interviewers Test Capacity Math First:

1. Dictates ArchitectureIf QPS is 50, a simple $5 instance works. If QPS is 500,000, you need an ingress proxy, auto-scaling clusters, and Redis caching tiers.

2. Sizes Persistent StorageTells you whether your database can live on a single 2 TB SSD or requires horizontal database sharding across 50 nodes.

3. Prevents Network ChokingIdentifies whether egress bandwidth exceeds gigabit boundaries and requires a global Content Delivery Network (CDN).

Section 02 · Core Foundations

The 5 Golden Sizing Formulas

Every capacity estimation question in existence boils down to these 5 mathematical pillars. Let's walk through them using real Twitter/X scale as our benchmark:

Queries Per Second (QPS)

TRAFFIC VOLUME

Tells you how many requests hit your servers every single second.

Average QPS = Daily Total Requests ÷ 86,400 seconds

💡 Mental Shortcut: 86,400 is close to 100,000 (10⁵). Simply drop 5 zeros from your daily volume to get a rapid ballpark estimation.

Peak QPS (Rush-Hour Multiplier)

AUTO-SCALING TARGET

Traffic is never flat. Sizing for average QPS causes your system to crash during evening rush hours or breaking viral news.

Peak QPS = Average QPS × Peak Multiplier (2× to 5×)

💡 Interview Standard: When an interviewer doesn't specify, assume a 2× multiplier for social apps, and 3× to 5× for flash sales (e-commerce) or live sports events.

5-Year Storage Capacity (With Replication)

DISK RETENTION

Calculates persistent disk growth. FAANG interviewers universally expect a 5-year planning horizon.

Daily Ingress = Daily Writes × Average Payload Size

5-Year Storage = Daily Ingress × 365 days × 5 years × Replication Factor (3×)

💡 The 3× Replication Rule: Production databases never store only 1 copy. Data is duplicated across 3 separate machines (primary + 2 replicas) to survive disk crashes. Your raw disk requirement triples!

Memory (RAM) Caching (The 80/20 Pareto Rule)

SPEED LAYER

RAM is expensive; you cannot store your entire database in memory. Fortunately, 20% of data generates 80% of reads.

Daily Read Volume = Daily Reads × Average Read Payload Size

RAM Cache Needed = Daily Read Volume × 20%

💡 High-ROI Architecture: Keeping just the hottest 20% working set in Redis or Memcached relieves 80% of read traffic from ever touching your disk-bound database.

Network Bandwidth (The Byte vs Bit Rule)

NETWORK PIPE

Calculates how much data your network interface cards (NICs) must push out every second.

Bandwidth (bps) = QPS × Payload Size (Bytes) × 8 bits/Byte

⚠️ The #1 Interview Trap: Storage is counted in Bytes (capital B), but network throughput is measured in Bits (lowercase b). Never forget to multiply by 8 when calculating network capacity!

Section 03 · Whiteboard Companion

The Architect's Mental Math Cheatsheet

Explore the interactive tabs below to master the 86,400 shortcut, powers-of-two storage ladder, latency in human perspective, and the 80/20 Pareto caching principle:

⚡WHITEBOARD SURVIVAL CHEATSHEET

Mental Math Shortcuts for Interviews

Never calculate to the decimal in an architecture interview. Master the 4 mental shortcuts that senior architects use to estimate massive systems in seconds.

The Secret: Drop 5 Zeros

How to Divide by 86,400 in Your Head

One day has 86,400 seconds (24h × 60m × 60s). In an interview, never divide by 86,400. Round it up to 100,000 (10⁵)!

💡 The Rule: To find QPS, simply take your daily requests and knock off 5 zeros. If you want more precision, add ~15% back.

Interviewer asks: "What is the QPS for 100 Million daily requests?"
You answer: "100M divided by 100k is ~1,000 QPS (exact is 1,157 QPS)." Ballpark verified in 2 seconds!

🧪 Try the Shortcut CalculatorLive Comparison

Enter Daily Requests (in Millions):

Million / Day

Mental Shortcut (÷100k)~2,500 QPS2-second mental math

Exact Division (÷86,400)2,893 QPSWithin 13% error

Memory & Storage Scaling

The Powers of Two Rulebook

Computers operate in base 2. In system design math, every step up by $2^10$ represents a 1,000× jump in scale:

Power	Exact Value	Ballpark Approx	Storage Unit
2¹⁰	1,024	~1 Thousand	1 KB (Kilobyte)
2²⁰	1,048,576	~1 Million	1 MB (Megabyte)
2³⁰	1,073,741,824	~1 Billion	1 GB (Gigabyte)
2⁴⁰	1,099,511,627,776	~1 Trillion	1 TB (Terabyte)
2⁵⁰	1,125,899,906,842,624	~1 Quadrillion	1 PB (Petabyte)

3 Golden Multipliers Every Architect Memorizes

Rule 1: 1 Million × 1 KB = 1 Gigabyte (GB)

Example: 10 Million users storing a 1 KB profile record = 10 GB total database storage.

Rule 2: 1 Million × 1 MB = 1 Terabyte (TB)

Example: 5 Million users uploading a 1 MB image = 5 TB daily object storage ingress.

Rule 3: 1 Billion × 1 KB = 1 Terabyte (TB)

Example: 1 Billion URL redirect records @ 1 KB each = 1 TB key-value storage.

Jeff Dean's Numbers Every Programmer Should Know

Computer Latency Scaled to Human Perspective

Nanoseconds and milliseconds are hard for our brains to intuitively grasp. If 1 L1 CPU cache reference (0.5 ns) were 1 human heartbeat (1 second), look at how astronomical disk and cross-continent network calls become:

L1 CPU Cache0.5 ns🚶 Human Scale: 1 single heartbeat (1 second)

Main Memory (RAM)100 ns☕ Human Scale: A brisk 3-minute stroll

NVMe SSD Random Read100 µs (0.1 ms)🚗 Human Scale: A 2-day cross-country road trip

Cross-Continent WAN150 ms🚀 Human Scale: 5 years of interplanetary space flight!

💡The Architectural Rule: Reading from RAM is ~1,000× faster than reading from SSD, and over 1,000,000× faster than going across a transatlantic network! This is why caches and CDN Edge servers exist.

The Pareto Caching Law

Why 20% Memory Saves 80% Database Load

In almost every real-world application, user interest follows a power-law distribution: 20% of content generates 80% of all read requests.

On Twitter, users read trending tweets, not obscure tweets from 5 years ago. On YouTube, people stream viral hits, not unlisted family videos. Therefore, sizing your RAM cache to hold just the top 20% of daily read volume shields your relational database from 80% of read load!

🧠 Interactive 80/20 RAM SizerFormula ④

Daily Read Volume:5.0 TB / day

RAM Cache Needed (20%)1.0 TB RAM~4 Redis instances (256GB each)

Requests Served From Cache80% Traffic ⚡Only 20% hits primary database

Section 04 · Simulation Laboratory

Live System Capacity Estimator

Put the 5 formulas to work. Pick a preset architecture (Twitter, Instagram, YouTube, TinyURL, or WhatsApp) or slide the controls to watch traffic, storage, cache, and server nodes calculate in real-time:

🧮INTERACTIVE SIZING LAB

Live System Capacity Estimator

Select a real-world FAANG archetype or drag the sliders below to calculate real-time QPS, storage footprint, caching memory, and server fleet sizing.

Daily Active Users (DAU):300 Million

1M (Startup)500M1,000M (1 Billion)

Reads / Views per User / Day:50 reads

1 read150 reads300 reads

Writes / Posts per User / Day:1 write

0.1 (Lurkers)10 writes30 writes

Average QPSFormula ①

177,083

Reads: 173.6kWrites: 3.5k

Peak Surge QPSFormula ②

354,167

⚡ Sizing target for Auto-Scaling Groups

Daily Storage IngressFormula ③

8.58 TB / day

300M writes/day @ 30 KB

5-Year Persistent StorageFormula ③

46.99 PB

Includes 3× replication factor

RAM (80/20 Working Set)Formula ④

28.61 TB RAM

🧠 Caching top 20% reads satisfies ~80% traffic

Outbound Network EgressFormula ⑤

13.89 Gbps

🌐 Multiplied by 8 bits/Byte for ISP pipe

🏢Estimated Hardware Fleet Sizing

REAL-WORLD BLUEPRINT

Stateless Web Fleet71 Nodes@ 5k Peak QPS / Node

Redis Cache Cluster115 Nodes@ 256 GB RAM / Node

Database Shards5 Shards@ 10 TB NVMe / Shard

Section 05 · Hands-On Studio Practice

Try It Yourself in Architecture Studio

Now that you've calculated the numbers for 50,000 Peak QPS, 20% hot RAM caching, and 5-year persistent storage, open our full-screen Architecture Studio to wire the complete multi-tier topology:

📐 STUDIO HANDS-ON LABBeginner⏱ 8–10 mins

Challenge 03: Architect Capacity & Sizing Tiers

Open Architecture Studio↗

The Challenge Scenario

You just sized a high-throughput social service handling 50,000 Peak QPS, 20% hot RAM cache, and multi-petabyte persistent storage. Open the studio and wire the multi-tier topology: distribute traffic from Users through a Load Balancer to a Stateless Server Fleet, query Redis Cache for fast memory reads, and persist writes into a sharded Database Cluster.

Components You Will Place in Studio:Available in Studio Palette

Users (50k Peak QPS)Load Balancer (Ingress Sizer)App Server Fleet (Stateless Workers)Redis Cache (80/20 RAM Working Set)Database Cluster (5-Year Storage Shards)Object Storage (Media Buckets)

Recommended Architecture Blueprint:

1Step 1: Ingress Load Balancing

Users → Load Balancer

At 50,000 Peak QPS, incoming connections must be terminated by a dedicated load balancer to avoid single-node socket exhaustion.

2Step 2: Stateless Worker Fleet

Load Balancer → App Server Fleet

Distributes 50k QPS across 10+ stateless worker nodes (~5,000 QPS capacity per instance).

3Step 3: In-Memory Speed Tier

App Server Fleet → Redis Cache

Caches the top 20% of read volume in memory, shielding the persistent database from 80% of read traffic.

4Step 4: Persistent Data Store

App Server Fleet → Database Cluster

Writes long-term data to replicated database shards designed for 5-year data retention.

Section 06 · Knowledge Check

Capacity Math Checkpoint

Lock in the core principles before advancing to Module 1.4:

🎯 QUICK INTUITION CHECK

Check Your Understanding

4 quick questions to lock in the 5 capacity math formulas before moving to Module 1.4.

Score: 0 / 4

An interviewer says your system will receive 432 Million requests every day. Using the whiteboard shortcut, what is the approximate average QPS?

Why must you always calculate Peak QPS (typically 2× to 5×) rather than sizing your server fleet solely for Average QPS?

Your service receives 1 TB of new data writes daily. If you plan for a 5-year retention window with industry-standard 3× replication, how much raw disk storage is required?

According to the Pareto Principle (80/20 Caching Rule), if your system receives 5 TB of read volume per day, how much RAM should your Redis cache fleet have?

○

Knowledge Check

Mastered this Architecture Concept?

Mark this module complete to record mastery in your HLD curriculum progress.

←

Previous ModuleVertical vs Horizontal Scaling

Next ModuleThe 4-Step Interview Framework

→