SYSTEM DESIGN:Lesson 3: Back-of-Envelope Estimation

What you need from this lesson

In a system design interview you will be asked for rough numbers: QPS, storage, bandwidth. You have about five minutes. Round numbers are fine. Exact spreadsheet math is not what they want.

You will learn:

1. One worked example (URL shortener) you can say out loud
2. A few numbers to memorize (seconds in a day, powers of 2, latency order)
3. How to turn any product into QPS → storage → bandwidth

Full URL shortener design comes later (Lessons 7–8). Here we only do the napkin math.

Back-of-envelope math on a coffee-stained napkin

Memorize these three first

Example: 10 million requests per day → 10M ÷ 100K ≈ 100 QPS average. Peak maybe 300–500 QPS.

Worked example: URL shortener

Say these assumptions with the interviewer before you calculate:

New short links per day:     100 million
Reads (redirects) vs writes: 100 : 1
Bytes stored per link:       ~600 bytes
Keep data for:               10 years
Peak:                        3× average

Writes

100M / day ÷ 100K sec/day ≈ 1,000 writes/sec average
Peak (3×):                  ~3,000 writes/sec

One Postgres primary can handle that. Writes are not the hard part.

Reads

1,000 writes/sec × 100 = 100,000 reads/sec average
Peak (3×):               ~300,000 reads/sec

That is why URL shorteners need Redis + CDN. You cannot send 300K QPS to one database.

Storage (10 years)

100M/day × 365 × 10 ≈ 365 billion rows
365B × 600 bytes    ≈ 220 TB raw
With 3 copies:      ≈ 660 TB

Shape of the problem: small writes, huge reads, disk grows every year.

Bandwidth

Peak reads: 300,000/sec
Redirect response: ~500 bytes
Outbound ≈ 300K × 500 B ≈ 150 MB/sec ≈ 1.2 Gbps
If CDN hits 95%: origin only sees ~5% of that

Sanity check

Memorize this one example. When they say “design a URL shortener,” put these four numbers on the board in the first five minutes.

The same method for any product

1. Users — DAU, and how many requests each makes per day
2. QPS — daily requests ÷ 100K; multiply by peak factor
3. Read vs write — feeds and search are read-heavy; payments are write-sensitive
4. Storage — rows × bytes × years × replicas
5. Bandwidth — QPS × response size (videos explode this number)

If a number feels wrong, say so out loud and adjust. Interviewers care that you check yourself.

Second example: social feed (short)

Assumptions:

DAU:              50 million
Feed refreshes:   20 per user per day
New posts:        5 million per day
Avg post size:    2 KB (text + metadata)
Peak:             5× (evening)

Feed reads/day: 50M × 20 = 1 billion
Read QPS avg:   1B ÷ 100K ≈ 10,000/sec
Read QPS peak:  ~50,000/sec

Write QPS avg:  5M ÷ 100K ≈ 50/sec
Write QPS peak: ~250/sec

Storage/year:   5M × 365 × 2 KB ≈ 3.5 TB raw text
(Images/video are separate — often object storage + CDN)

Again: reads dwarf writes. That is why feeds use caches and fan-out designs — not one giant SQL query per refresh.

Latency: order of magnitude only

You do not need exact nanoseconds. You need the order:

Rule of thumb: if your design does 50 sequential DB calls, users will feel it. Prefer fewer round trips and caching for hot data.

Latency cheat sheet from L1 cache to cross-continent RPC

The insight that changes how you design:

Memory is 100,000x faster than disk. Redis is 10x faster than Postgres. A same-datacenter call is 100x faster than a cross-country one. Every time you add a network hop, you add milliseconds. Design accordingly.

Budget for a 200ms API response:
  Load balancer:        1 ms
  App server logic:     5 ms
  Redis cache lookup:   1 ms
  Postgres query:       10 ms
  Serialization:        2 ms
  Network to client:    50 ms (India mobile)
  ─────────────────────────
  Total:               ~70 ms  ✓ well within budget

Same request with 5 sequential Postgres queries:
  5 × 10 ms = 50 ms just in DB → 110 ms total → getting tight

CPU on the app server in this budget: 5 ms logic + 2 ms serialization = 7 ms
4 cores ÷ 0.007 s ≈ 571 RPS (about 570)
The other lines are waiting: load balancer, Redis, Postgres, network to the client

This is why caching matters. This is why you batch database queries. This is why putting your servers in Mumbai for an Indian user base is not optional.

Powers of 2 (when you need storage size)

Shortcut: every +10 in the exponent ≈ ×1,000.

QPS estimation flow from DAU to peak requests

The formula:

Daily requests = DAU × requests per user per day
Average QPS  = daily requests / 100,000  (seconds in a day, rounded)
Peak QPS     = average QPS × peak multiplier

Peak multiplier rule of thumb:

Quick example:

Product: Twitter-like app in India
DAU: 10 million
Requests per user per day: 100 (scroll feed, post, like, refresh)

Daily requests = 10M × 100 = 1 billion
Average QPS    = 1B / 100K = 10,000
Peak QPS (3x)  = 30,000

30,000 QPS is a serious number. You need load-balanced app servers, read replicas, caching, and probably a CDN. A 4-core server tops out at about 1,000–5,000 QPS for a light I/O-bound API when CPU time is about 0.8–4 ms per request (4 ÷ 0.004 = 1,000; 4 ÷ 0.0008 = 5,000). The rest of the latency is waiting. The 7 ms budget above is heavier: about 570 RPS, under that range. For this 1,000–5,000 range you need at least 6–30 app servers at peak. Those 6–30 servers are the light case. The 7 ms handler needs about 53 servers for 30,000 QPS (30,000 ÷ 571 ≈ 52.5) and about 131 for 75,000 read QPS (75,000 ÷ 571 ≈ 131), at about 570 RPS each. The worked version is in Scaling Basics.

Read vs write QPS:

If read:write ratio is 100:1 and total QPS is 30,000:
  Read QPS  = 29,700
  Write QPS = 300

This split tells you where to invest: 29,700 reads/sec screams for caching and read replicas. 300 writes/sec is manageable on a single well-tuned primary database.

Common mistakes

What to say in the interview (script)

1. “I’ll assume X DAU and Y actions per day — OK?”
2. “That’s about Z QPS average, peak roughly 3×.”
3. “Reads vs writes look like A:B, so I’ll size cache for reads.”
4. “Storage over N years is about T TB raw.”
5. “Does that match the scale you had in mind?”

Then draw the boxes. Numbers first, architecture second.

Checklist

• [ ] Daily ÷ 100K → average QPS
• [ ] Apply a peak multiplier
• [ ] Separate read QPS and write QPS
• [ ] Storage = rows × size × years × replicas
• [ ] Bandwidth = QPS × response size
• [ ] Sanity-check against one known example (URL shortener)

Let us estimate everything for a Twitter/X-like social feed targeting the Indian market. This is the kind of problem you get in a 45-minute system design interview.

Step 1 — Clarify assumptions

DAU:                    50 million
Posts per user per day:   2
Feed refreshes per day:   50
Followers per user (avg): 200
Post size:                500 bytes (text + metadata)
Feed page size:           20 posts × 500 bytes = 10 KB
Read:write ratio:         25:1
Peak multiplier:          3x

Step 2 — Calculate QPS

Writes per day  = 50M users × 2 posts   = 100M
Reads per day   = 50M users × 50 refreshes = 2.5B
Total per day   = 2.6B requests

Average QPS = 2.6B / 100K = 26,000
Peak QPS    = 26,000 × 3 = 78,000

Write QPS (peak) = 78,000 / 26 = 3,000
Read QPS (peak)  = 75,000

Step 3 — Calculate storage

Posts per day:     100 million
Storage per day:   100M × 500 bytes = 50 GB/day
Storage per year:  50 GB × 365 = ~18 TB/year
5-year retention:  ~90 TB
With 3x replication: ~270 TB

Step 4 — Calculate bandwidth

Read bandwidth (peak) = 75,000 QPS × 10 KB = 750 MB/sec = 6 Gbps
Write bandwidth (peak) = 3,000 QPS × 500 bytes = 1.5 MB/sec

Step 5 — Capacity plan

App servers:    75,000 read QPS / 2,000 per server = ~40 servers (with headroom: 60)
  (2,000 per server assumes 2 ms of CPU on 4 cores: 4 ÷ 0.002 = 2,000.)
  (Light case. The 7 ms handler is about 570 RPS: 75,000 ÷ 571 ≈ 131 servers.)
Redis cache:    Hot feed for active users, ~20 GB memory
Read replicas:  3 replicas handling 25,000 QPS each
Primary DB:     3,000 write QPS — needs careful indexing, possibly sharding
CDN:            Offload media, reduce origin bandwidth by 90%

The 2,000-per-server line (~40 servers) is the light case from Scaling Basics. The 7 ms handler on this page is about 570 RPS, so 75,000 read QPS needs about 131 servers (75,000 ÷ 571 ≈ 131) and 30,000 QPS needs about 53 (30,000 ÷ 571 ≈ 52.5).

Step 6 — Sanity check

The write QPS of 3,000 is the number to flag in an interview. It is fine today with a well-tuned primary, but you should mention sharding as a future consideration when writes exceed 5,000/sec.

Estimation shortcuts for interviews

Memorize these. They save you three minutes every time.

1 million users × 10 requests/day = 10M requests/day ≈ 100 QPS average
10 million users × 100 requests/day = 1B requests/day ≈ 10,000 QPS average
100 million users × 10 requests/day = 1B requests/day ≈ 10,000 QPS average

1 four-core server ≈ 1,000–5,000 QPS for a light I/O-bound API (0.8–4 ms of CPU: 4 ÷ 0.004 = 1,000, 4 ÷ 0.0008 = 5,000)
1 Postgres primary ≈ 1,000–10,000 write QPS (depends on query complexity)
1 Redis instance ≈ 100,000 ops/sec
1 GB RAM ≈ 1 million small cached objects

The 80/20 rule for estimation:

You can size a problem. Next: the interview framework — how to run the full 45 minutes without getting lost.

Related: Scaling basics · Data layer · URL shortener