Step 2: Estimate Scale & Bottlenecks

Why Estimation Matters

After you understand the requirements, the next question is: how big is this system? The answer determines everything that follows. A system serving 1,000 users per day and a system serving 500 million users per day have almost nothing in common architecturally. One runs on a single server. The other requires distributed databases, sharding, caching layers, and CDN infrastructure across multiple continents.

Back-of-the-envelope estimation is the bridge between requirements and architecture. You take the user-level numbers (daily active users, actions per user) and convert them into system-level numbers (queries per second, storage per day, bandwidth). These numbers tell you which components are necessary and which are overkill.

The Estimation Cascade

Every estimation follows the same cascade. You start with users and work your way down to infrastructure numbers.

Key Estimation Formulas

Memorize these formulas. They appear in nearly every system design problem.

Worked Example: WhatsApp Messaging

Let us walk through a full estimation for WhatsApp text messaging. These are the assumed inputs from Session 6.1.

Given:

• 500 million DAU
• Each user sends 40 messages per day (average)
• Average message size: 100 bytes (text content + metadata)

Step 1: Write QPS.

Total messages per day = 500,000,000 × 40 = 20,000,000,000 (20 billion).

Write QPS = 20,000,000,000 ÷ 86,400 ≈ 231,481 writes/second.

Peak QPS (3x factor) ≈ 694,444 writes/second.

Step 2: Daily storage.

Daily storage = 20,000,000,000 × 100 bytes = 2,000,000,000,000 bytes ≈ 1.86 TB/day.

Step 3: Yearly storage.

Yearly storage = 1.86 TB × 365 ≈ 679 TB/year.

With 3x replication = 679 × 3 ≈ 2,037 TB ≈ 2 PB/year.

Step 4: Bandwidth.

Ingress bandwidth = 231,481 × 100 bytes ≈ 23 MB/s (incoming messages).

Egress bandwidth depends on fan-out. If each message is read once (1:1 chat), egress ≈ ingress ≈ 23 MB/s. For group messages, multiply by average group size.

Step 5: Cache memory.

If we cache 20% of daily messages: 0.2 × 1.86 TB ≈ 372 GB of cache. This fits comfortably in a Redis cluster.

Visualizing the Cascade

The logarithmic scale is deliberate. These numbers span wildly different orders of magnitude, and that is exactly the point. QPS is in the hundreds of thousands. Storage is in the terabytes and petabytes. Your job is not to compute these to three decimal places. Your job is to know whether you are dealing with gigabytes or petabytes, because the architecture for each is fundamentally different.

Common Estimation Shortcuts

A few useful approximations to keep in your head during interviews:

What Interviewers Are Looking For

The interviewer does not expect you to produce exact numbers. They want to see three things.

Structured reasoning. You follow a repeatable process: users to actions to QPS to storage. You do not guess.

Order-of-magnitude awareness. When you say "about 200,000 QPS," the interviewer knows you understand this is a large-scale system that needs distributed infrastructure. If you said "200 QPS" with the same inputs, that signals a fundamental miscalculation.

Connection to architecture. The numbers should inform your design. "At 700K peak QPS, a single database will not handle this. We need sharding." That is the sentence that turns estimation from a math exercise into an engineering decision.

Further Reading

• System Design Interview, Vol. 1 by Alex Xu, Chapter 2: Back-of-the-envelope Estimation
• High Scalability: Google Pro Tip, Use Back-of-the-Envelope Calculations
• Latency Numbers Every Programmer Should Know (interactive visualization)
• System Design Primer: Back-of-the-envelope Calculations