One-liner: Rough estimates done quickly to understand the scale of a system before designing it. They tell you what tier of infrastructure you need.
๐ Why This Matters
Before designing ANY system, you need to know:
- How many users will use it?
- How many requests per second?
- How much storage do we need?
- How much bandwidth is required?
These estimates shape every architectural decision.
๐ข Numbers Every Engineer Should Know
Time
| Unit | Value |
|---|---|
| 1 millisecond | 10โปยณ seconds |
| 1 microsecond | 10โปโถ seconds |
| 1 nanosecond | 10โปโน seconds |
| Seconds in a day | ~86,400 โ 10โต |
| Seconds in a month | ~2.5M โ 2.5 ร 10โถ |
| Seconds in a year | ~31.5M โ 3 ร 10โท |
Latency Numbers (Approximate)
| Operation | Latency |
|---|---|
| L1 cache reference | 1 ns |
| L2 cache reference | 4 ns |
| RAM reference | 100 ns |
| SSD random read | 150 ยตs |
| HDD seek | 10 ms |
| Network: same datacenter | 500 ยตs |
| Network: cross-region (USโEU) | 150 ms |
| Network: cross-continent | 200โ300 ms |
Storage Units
| Unit | Size |
|---|---|
| 1 KB | 10ยณ bytes |
| 1 MB | 10โถ bytes |
| 1 GB | 10โน bytes |
| 1 TB | 10ยนยฒ bytes |
| 1 PB | 10ยนโต bytes |
๐ The Estimation Framework
Step 1: DAU โ QPS
Daily Active Users (DAU) = 10 million
Avg requests per user/day = 10
Total daily requests = 100 million
QPS = 100M / 86,400 โ 1,200 req/sec
Peak QPS (2-3x average) โ 3,000 req/sec
Step 2: Storage
New posts per day = 1M
Avg post size = 1 KB (text) + 500 KB (image)
Daily storage = 1M ร 501 KB โ 500 GB/day
Yearly storage = 500 GB ร 365 โ 180 TB/year
5-year storage โ 1 PB
Step 3: Bandwidth
Reads per second = 100K req/sec
Avg response size = 10 KB
Outbound bandwidth = 100K ร 10 KB = 1 GB/sec
๐ฌ Real Example: Design Twitter
Assumptions
- 300M DAU
- Each user reads 10 tweets/day
- Each user writes 1 tweet/week โ 0.14 tweets/day
- Avg tweet: 280 chars = 280 bytes โ 300 bytes
- 10% of tweets have an image (~200 KB)
Read QPS
300M users ร 10 reads/day = 3B reads/day
QPS = 3B / 86,400 โ 35,000 reads/sec
Peak QPS โ 100,000 reads/sec
Write QPS
300M ร 0.14 = 42M tweets/day
QPS = 42M / 86,400 โ 500 writes/sec
Storage per day
Text: 42M ร 300 bytes = 12.6 GB
Images: 42M ร 10% ร 200 KB = 840 GB
Total: ~850 GB/day โ 310 TB/year
Bandwidth
Read traffic: 35K req/sec ร 1 KB/response โ 35 MB/sec = ~300 Gbps
๐ฌ Real Example: Design WhatsApp
Assumptions
- 2B DAU
- Each user sends 20 messages/day
- Avg message: 100 bytes
- 30% are media messages (500 KB avg)
QPS
2B ร 20 = 40B messages/day
QPS = 40B / 86,400 โ 460,000 msg/sec
Peak QPS โ 1M msg/sec
Storage per day
Text: 40B ร 100B = 4 TB
Media: 40B ร 30% ร 500 KB = 6 PB/day (too high โ add retention/compression policy)
๐ก Tips for Interviews
- Always ask before estimating โ "Should I assume 10M or 100M users?"
- Round aggressively โ 86,400 โ 10โต, 3.14 โ 3
- Peak = 2-3ร average (or 5-10ร for viral/event-based systems)
- Show your math โ interviewers care about the process, not the exact number
- Derive storage needs from estimates โ don't pull numbers from thin air
- 1 char = 1 byte (ASCII), 1 char = 2-4 bytes (Unicode)
๐ Estimation Cheat Sheet
1K users โ Single server fine
10K users โ Need to think about DB separation
100K users โ Load balancer, read replicas
1M users โ Caching layer, CDN, sharding
10M users โ Distributed systems, microservices
100M+ โ You work at a FAANG (or interview there)
๐ Key Takeaways
- Back-of-envelope is about order of magnitude, not precision
- Know the key numbers cold: bytes, seconds in a day, latency tiers
- Always separate read QPS from write QPS โ they're usually very different
- Storage estimations reveal whether you need sharding/archival early
Top comments (0)