Back of the Envelope Estimation

Back-of-the-envelope calculations are rough, quick estimates used to gauge how much infrastructure, bandwidth, or storage your system might need before doing detailed planning.

Think of it as engineering intuition: you don't need precise numbers, just enough to make decisions and sanity-check feasibility.

Why It's Important

When scaling systems to millions of users:

• You need to know how many servers you might need.
• You need to know how much bandwidth or storage to provision.
• You need to know if your architecture can handle peak loads.

BoE estimations allow you to answer these questions quickly, without waiting for detailed load testing or simulations.

Power of Two

In computer systems, most resources – memory, storage, network buffers – are organized in powers of two:

1, 2, 4, 8, 16, 32, 64, 128,…

This is because binary systems in computers naturally allocate memory and storage blocks of 2^n.

Why Powers of Two Are Useful in BoE

1. Rough estimation is easier
   1. Instead of calculating exact numbers, rounding to the nearest power of two gives a good approximation.
   2. Example: If you need 3,000 users per DB shard, estimate 4,096 users per shard -> simplifies planning.
2. Memory alignment
   1. Most RAM and disk blocks are sized in powers of two (e.g., 4 KB pages).
   2. Estimating in powers of two avoids underestimating resource needs.
3. Network and bandwidth calculations
   1. Buffers, packet sizes, and throughput often scale in powers of two.
4. Server and cluster scaling
   1. Horizontal scaling often doubles capacity (2, 4, 8, 16 servers) -> fits naturally with powers of two.

Example:

Suppose your back-of-the-envelope calculation shows you need 7 web servers.

• Using powers of two, you round up to 8 servers.
• This makes load balancing and partitioning simpler, and keeps a spare for failover.

Quick Reference of Powers of Two

Queries Per Second (QPS)

The number of queries (read or write) a system (usually a database) received per second.

It's one of the most important metrics in capacity planning because it tells you how much load your database or API needs to handle.

Read queries: Select

Write queries: Insert, Update, and Delete

Storage Units

When building systems that scale to millions of user, you need to estimate how much storage your data will occupy. To do that, it's essential to understand storage units and how they scale.

Common Storage Units

Back of the envelope estimation of Instagram

Assumptions

1. Monthly Active users: ~2 Billion

   60% of these users use insta daily: ~1.2 Billion (DAU: Daily Active Users)

2. User See feed: (1 Feed request – 1 Query)
   or User Post photo/video/reel (1 Post request – 1 Query)
3. User check feed 30 times a day (Average)
4. Estimate for 5 years
5. User publishes 1 picture/reel a day (Average)

Feed View QPS

Feed request per seconds in Instagram:

Daily Feed Request: (DAU * 30 times) / (24* 3600) seconds
: (1.2B * 30) / 86400
: ~420K/sec

Peak QPS

Peak QPS: 2*QPS
: ~420K * 2
: ~840K/sec

Upload QPS

Daily Upload Request: (1.2B * 1/86400)
: ~14K/sec

Peak QPS: 2*QPS
: ~14K * 2
: ~28K/sec

Storage Unit:

Assumptions:

• 20% of users upload video
  • A single video is 50MB (Average)
• 80% of users upload photo
  • A single photo is 1MB (Average)

Photos/day:

photos/day = 1.2B*80% = ~1B * 1MB
= 2^30*1*2^20
= 2^50
= ~1 PB

Videos/day:

videos/day = 1.2B*20% = ~0.25B
= ~0.25B * 50MB
= 0.25*2^30 * 50*2^20
= 2^50 * 0.25*50
= 2^50 * 12
= ~12 PB

Total:

= Photos/day + Videos/day
= 1PB + 12PB
= 13 PB

This much storage is needed for a single day for storing photos and video.

Calculate for 5 years:

13PB * 365*5
= ~24000 PB
= 24*10^3
= 24 * 2^10 * 2^50
= 24 * 2^60
= 24 EB (Exabyte)