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

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

Always estimate first.

Design later.

The Ultimate Estimation Cheat Sheet

Storage Units

Time Units

Common Assumptions

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

Not every user is active daily.

Let's assume:

20% Daily Active Users

Therefore:

DAU = 1 Billion × 20%

DAU = 200 Million Users

Step 2: Traffic Estimation

Assume each active user opens Facebook:

10 times per day

Total daily requests:

200 Million × 10

= 2 Billion Requests / Day

Now convert this into Requests Per Second (RPS).

2,000,000,000 / 86,400

≈ 23,000 RPS

Peak Traffic Estimation

Traffic is never evenly distributed.

Peak traffic is usually around:

3 × Average Traffic

Therefore:

Peak RPS

= 23,000 × 3

≈ 70,000 RPS

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

Step 3: Number of Servers Required

Assume:

1 Application Server

Handles 10,000 RPS

Required servers:

70,000 / 10,000

= 7 Servers

Always keep extra capacity for failures and traffic spikes.

So we provision:

10 Servers

Final Estimate

Application Servers Needed ≈ 10

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

Storage required:

1 Billion × 1 KB

= 1 TB

User profiles consume surprisingly little storage.

Post Storage

Assume every active user creates:

1 Post / Day

Daily posts:

200 Million Posts

Average post size:

5 KB

Storage:

200 Million × 5 KB

≈ 1 TB / Day

Image Storage

This is where the real storage explosion happens.

Assume:

50 Million Images Uploaded Daily

Average image size:

500 KB

Storage:

50 Million × 500 KB

≈ 25 TB / Day

Total Daily Storage

Posts  = 1 TB
Images = 25 TB

Total = 26 TB / Day

Annual Storage Growth

26 × 365

≈ 9,500 TB

≈ 9.5 PB

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

(Pareto Principle)

Assume total active data:

1 TB

Frequently accessed data:

20%

= 200 GB

Required Cache Size

Adding some safety buffer:

200 GB + Buffer

≈ 300 GB Cache

Cache Servers Required

Assume:

1 Redis Server

100 GB RAM

Then:

300 / 100

= 3 Cache Servers

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

Final Facebook Estimation

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

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.

Say:

Let's assume 1 billion users.

Forgetting Peak Traffic

Always calculate:

Peak RPS

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

• 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?