HLD Fundamentas #7: Back-of-the-Envelope Calculations

When designing systems like Facebook, WhatsApp, Netflix, Amazon, or Instagram, one of the first questions a system designer asks is:

• Can a single server handle the traffic?
• How much storage will be needed?
• Do we need caching?
• How much RAM should our cache have?
• How many servers should we deploy?

Before discussing databases, load balancers, microservices, or caching layers, we need a rough understanding of the scale.

This is where Back-of-the-Envelope Calculations come into the picture.

Why Do We Need Back-of-the-Envelope Calculations?

Imagine you’re asked to design Facebook.

If you immediately start drawing:

Load Balancer
     ↓
Application Servers
     ↓
Redis Cache
     ↓
Database

Enter fullscreen mode Exit fullscreen mode

without knowing the expected traffic, you’re designing blindly.

System design is fundamentally about making trade-offs.

To make those trade-offs, we first need estimates.

Back-of-the-envelope calculations help us answer:

• How much traffic will the system receive?
• How much data will be generated?
• How much cache memory is required?
• How many servers are needed?

The numbers don’t need to be perfect.

They only need to be close enough to make architectural decisions.

What Exactly Is a Back-of-the-Envelope Calculation?

A quick estimation technique used to approximate:

• Traffic
• Storage
• Memory
• Server Capacity

using rough assumptions.

Think of it as:

“Getting the order of magnitude correct rather than getting the exact number correct.”

A system designer rarely needs perfect accuracy during interviews.

They need reasonable estimates.

The Standard Estimation Flow

Whenever you get a System Design question:

Users
  ↓
Traffic
  ↓
Storage
  ↓
RAM / Cache
  ↓
Number of Servers
  ↓
Architecture Design

Enter fullscreen mode Exit fullscreen mode

Always estimate first.

Design later.

The Ultimate Estimation Cheat Sheet

Storage Units

Unit Value 1 KB 10³ Bytes 1 MB 10⁶ Bytes 1 GB 10⁹ Bytes 1 TB 10¹² Bytes 1 PB 10¹⁵ Bytes

Time Units

Unit Value 1 Minute 60 Seconds 1 Hour 3600 Seconds 1 Day 86,400 Seconds

Common Assumptions

Metric Approximation Peak Traffic 3× Average Traffic Active Users 10-20% of Total Users Hot Data 20% of Total Data Cache Hit Data 80% of Requests

These assumptions are commonly used in interviews.

Example: Facebook Capacity Planning

Let’s walk through a complete example.

Step 1: User Estimation

Assume Facebook has:

1 Billion Registered Users

Enter fullscreen mode Exit fullscreen mode

Not every user is active daily.

Let’s assume:

20% Daily Active Users

Enter fullscreen mode Exit fullscreen mode

Therefore:

DAU = 1 Billion × 20%

DAU = 200 Million Users

Enter fullscreen mode Exit fullscreen mode

Step 2: Traffic Estimation

Assume each active user opens Facebook:

10 times per day

Enter fullscreen mode Exit fullscreen mode

Total daily requests:

200 Million × 10

= 2 Billion Requests / Day

Enter fullscreen mode Exit fullscreen mode

Now convert this into Requests Per Second (RPS).

2,000,000,000 / 86,400

≈ 23,000 RPS

Enter fullscreen mode Exit fullscreen mode

Peak Traffic Estimation

Traffic is never evenly distributed.

Peak traffic is usually around:

3 × Average Traffic

Enter fullscreen mode Exit fullscreen mode

Therefore:

Peak RPS

= 23,000 × 3

≈ 70,000 RPS

Enter fullscreen mode Exit fullscreen mode

[Insert architecture diagram here showing User → Load Balancer → Application Servers]

Step 3: Number of Servers Required

Assume:

1 Application Server

Handles 10,000 RPS

Enter fullscreen mode Exit fullscreen mode

Required servers:

70,000 / 10,000

= 7 Servers

Enter fullscreen mode Exit fullscreen mode

Always keep extra capacity for failures and traffic spikes.

So we provision:

10 Servers

Enter fullscreen mode Exit fullscreen mode

Final Estimate

Application Servers Needed ≈ 10

Enter fullscreen mode Exit fullscreen mode

Storage Estimation

Now let’s estimate how much storage Facebook needs.

User Profile Storage

Assume each user profile stores:

• Name
• Bio
• Settings
• Metadata

Approximate size:

1 KB per User

Enter fullscreen mode Exit fullscreen mode

Storage required:

1 Billion × 1 KB

= 1 TB

Enter fullscreen mode Exit fullscreen mode

User profiles consume surprisingly little storage.

Post Storage

Assume every active user creates:

1 Post / Day

Enter fullscreen mode Exit fullscreen mode

Daily posts:

200 Million Posts

Enter fullscreen mode Exit fullscreen mode

Average post size:

5 KB

Enter fullscreen mode Exit fullscreen mode

Storage:

200 Million × 5 KB

≈ 1 TB / Day

Enter fullscreen mode Exit fullscreen mode

Image Storage

This is where the real storage explosion happens.

Assume:

50 Million Images Uploaded Daily

Enter fullscreen mode Exit fullscreen mode

Average image size:

500 KB

Enter fullscreen mode Exit fullscreen mode

Storage:

50 Million × 500 KB

≈ 25 TB / Day

Enter fullscreen mode Exit fullscreen mode

Total Daily Storage

Posts  = 1 TB
Images = 25 TB

Total = 26 TB / Day

Enter fullscreen mode Exit fullscreen mode

Annual Storage Growth

26 × 365

≈ 9,500 TB

≈ 9.5 PB

Enter fullscreen mode Exit fullscreen mode

This explains why large social media platforms rely heavily on distributed storage systems.

[Insert diagram here showing Posts + Images → Distributed Storage Cluster]

RAM / Cache Estimation

Storage tells us how much data exists.

Cache tells us how much data needs to stay in memory.

Why Cache?

Fetching everything from a database is expensive.

Frequently accessed content should be stored in memory.

Examples:

• News Feed
• User Profiles
• Trending Posts
• Friend Lists

Hot Data Estimation

A common assumption is:

20% of data generates 80% of traffic

Enter fullscreen mode Exit fullscreen mode

(Pareto Principle)

Assume total active data:

1 TB

Enter fullscreen mode Exit fullscreen mode

Frequently accessed data:

20%

= 200 GB

Enter fullscreen mode Exit fullscreen mode

Required Cache Size

Adding some safety buffer:

200 GB + Buffer

≈ 300 GB Cache

Enter fullscreen mode Exit fullscreen mode

Cache Servers Required

Assume:

1 Redis Server

100 GB RAM

Enter fullscreen mode Exit fullscreen mode

Then:

300 / 100

= 3 Cache Servers

Enter fullscreen mode Exit fullscreen mode

[Insert architecture diagram here showing Application Layer → Redis Cache → Database]

Final Facebook Estimation

Metric Estimate Total Users 1 Billion Daily Active Users 200 Million Daily Requests 2 Billion Average RPS 23,000 Peak RPS 70,000 Application Servers 10 Daily Storage 26 TB Annual Storage 9.5 PB Cache Requirement 300 GB Redis Servers 3

Interview Tips

Whenever you’re asked to design:

• Facebook
• WhatsApp
• Instagram
• Netflix
• Uber
• YouTube

Don’t start with databases.

Start with:

Let's estimate:

1. Users
2. Traffic
3. Storage
4. Cache
5. Servers

Enter fullscreen mode Exit fullscreen mode

This immediately demonstrates senior-level thinking.

Interviewers love candidates who quantify before they architect.

Common Mistakes

Using Exact Numbers

Don’t say:

Facebook has exactly 3.07 billion users.

Enter fullscreen mode Exit fullscreen mode

Say:

Let's assume 1 billion users.

Enter fullscreen mode Exit fullscreen mode

Forgetting Peak Traffic

Always calculate:

Peak RPS

Enter fullscreen mode Exit fullscreen mode

because systems fail during peaks, not averages.

Ignoring Cache

Many candidates estimate storage but completely forget memory requirements.

In large-scale systems:

RAM is often more valuable than storage.

Trade-Offs

Approach Pros Cons No Estimation Faster Poor Design Decisions Back-of-the-Envelope Quick & Practical Approximate Detailed Capacity Planning Accurate Time Consuming

• Back-of-the-envelope calculations are rough estimates used before designing a system.
• Estimate Users → Traffic → Storage → Cache → Servers.
• Use assumptions instead of exact values.
• Always calculate both Average RPS and Peak RPS.
• Estimate storage growth annually.
• Estimate hot data for cache sizing.
• This skill is heavily tested in System Design Interviews.

System design is not about drawing architecture diagrams first.

It’s about understanding scale first and then choosing the right architecture.

How do you approach capacity planning during system design interviews? Do you estimate traffic first, storage first, or both together?