System Design Fundamentals

Back-of-the-envelope estimation

Friday 6:12 PM: dinner rush on Uber. Before you draw boxes, you need a feel for scale: how many matching requests per second, how much trip history to store, and whether map tiles need a .

That is what is for. You turn and actions into , storage, bandwidth, and server count. The difference between "1 TB" and "1 PB" decides the architecture long before you debate microservices.

Estimation journey

Multiply daily actives by actions per user to get daily volume.

Divide daily totals by about 86,400 seconds to get average rate.

Busy-hour load and ops buffer beat a tidy daily average every time.

Translate to architecture

Map the result to cache, CDN, shards, queues, and cost decisions.

What actually happens

The Friday rush story only works if you say the inputs out loud: users, actions, payload sizes, retention, and read/write ratio. Daily totals become average with 86,400 seconds per day. Then you multiply for and add so deploys and failures do not melt the fleet.

Storage estimates multiply object size × writes × retention × . Bandwidth estimates often force a decision long before you debate service boundaries. The helps size caches so most reads never hit the database.

Keep the calculation’s assumptions separate from measured facts. If daily users or average payloads are uncertain, calculate a plausible low and high case instead of presenting a detailed decimal as certainty. Then connect the result to a choice: a few hundred metadata writes per second may fit one database, while large media bandwidth can require a CDN even with modest request counts. Revisit only the assumptions that could change that decision.

How to choose what to estimate

Once you know you need a feel for scale, three questions decide which numbers matter and which you can skip for now.

1. What decision are you making? Database choice needs and payload size. Media products need storage and egress. Chat needs connection count as much as message rate.

2. Average or peak? Always show both. drives capacity; average drives cost narratives and baseline spend.

3. What did you forget to multiply? , indexes, backups, read amplification, and growth turn tidy numbers into real fleets.

Simple rule of thumb

Start from user behavior, divide daily actions by 86,400, and choose a peak factor from the workload. A 2–3× factor might suit relatively smooth global traffic, while a scheduled sale or one-region commute can be much burstier. Add headroom for deployments and failures explicitly instead of multiplying arbitrary cushions twice. The resulting estimate identifies which measurements would most influence architecture and capacity.

From problem to mechanism

The questions above tell you what to estimate; this is the repeatable path that turns and actions into capacity and storage decisions without fake precision.

Problem. An interviewer asks whether your design needs a cache, a , shards, or a queue, but you have no sense of scale yet.

Naive system. You jump to infrastructure guesses ("we'll need Kafka and Redis") before converting users into , storage, or bandwidth.

Break it. Averages hide ; missing and under-size the fleet; bit/byte mix-ups invent fake bandwidth crises.

Mechanism. State assumptions, keep units visible, use round numbers, run traffic and storage in parallel, then sanity-check cost, p99, and growth before locking the design.

Users and actions

DAU × actions/day

Estimate both dimensions

Traffic path

QPS

divide by 86,400

Peak

multiply by 2–3×

Capacity

servers, shards, cache

Storage path

Storage and bandwidth

size × retention × replication

Sanity check

cost, p99, growth

Numbers to know

The mechanism above needs a few memorized constants so you are not inventing units under pressure. Later sections and worked examples refer back here instead of restating every table.

Powers of 2

Power	Size
2^10	1 KB
2^20	1 MB
2^30	1 GB
2^40	1 TB
2^50	1 PB
2^60	1 EB

Latency hierarchy (2024)

Layer	Typical latency
L1 cache	~1 ns
L2 cache	~4 ns
RAM access	~100 ns
SSD random read	~100 μs (100,000 ns)
SSD sequential 1 MB	~1 ms
HDD seek	~10 ms
Network same datacenter	~500 μs (0.5 ms)
Network cross-region	~50–150 ms
Network cross-continent	~100–300 ms

Time conversions

Period	Seconds	Round
1 day	86,400 seconds	≈ 10^5 s
1 month	2.6M seconds	≈ 2.5 × 10^6 s
1 year	31.5M seconds	≈ 3 × 10^7 s

Typical payload sizes

Object	Size
Tweet / message	~300 bytes
JSON API response	~2–10 KB
Photo (compressed)	~200 KB – 2 MB
Video (1 min, 720p)	~10–50 MB
Database row	~200–500 bytes

Interview tip: 86,400 seconds per day is the constant that turns daily totals into . Round to 10⁵ for mental math.

Worked examples

With the constants from Numbers to know above, expand each example for assumptions, step-by-step math, and the headline metrics that drive architecture choices.

Photo-feed service storage and bandwidth

Assumptions

Users2B total, 500M DAU

Uploads50M photos/day

Size~3 MB/photo (original + resolutions)

RetentionForever

Metadata~500 bytes/photo

Calculations

1
Daily photo storage
50M × 3 MB
→ 150 TB/day
2
Yearly photo storage
150 TB × 365
→ ~55 PB/year
3
5-year + 3× replication
55 PB × 5 × 3
→ ~0.8 EB
4
Upload QPS (avg)
50M / 86,400
→ ~580/sec
5
Upload QPS (peak)
580 × 2–3
→ ~1,500/sec
6
View QPS (100:1 R/W)
580 × 100
→ ~58K avg, ~150K peak
7
View bandwidth (peak)
150K × 500 KB
→ 75 GB/s ≈ 600 Gbps → CDN required

150 TB

Storage / day

Photos only

~0.8 EB

5-year replicated

3× replication

~150K

Peak view QPS

100:1 read ratio

600 Gbps

Peak bandwidth

Origin cannot serve alone

Architecture signal: metadata (~100 TB over 5 years) is tiny next to blobs, but needs a fast database. Photo delivery at hundreds of Gbps requires a global CDN.

Messaging throughput and connections

Assumptions

Users2B total, 500M DAU

Messages40 messages/user/day

Text~300 bytes/message

Media10% of messages, ~200 KB each

Calculations

1
Messages per day
500M × 40
→ 20B/day
2
Message QPS (avg)
20B / 86,400
→ ~230K/sec
3
Message QPS (peak)
230K × 3
→ ~700K/sec
4
Text storage / day
20B × 300 bytes
→ 6 TB/day
5
Media storage / day
20B × 10% × 200 KB
→ 400 TB/day
6
Yearly storage
Text 2.2 PB + Media 146 PB
→ ~148 PB/year (media dominates)
7
Text bandwidth
230K × 300 B × 2 (send+recv)
→ ~1.1 Gbps
8
Media bandwidth
23K × 200 KB × 2
→ ~74 Gbps
9
WebSocket fleet
500M connections ÷ 50K/server
→ ~10,000 connection servers

~700K

Peak msg/sec

3× average

146 PB

Media storage/yr

Dominates cost

74 Gbps

Media bandwidth

Separate from text

~10K

Connection servers

50K conn/server

Architecture signal: retention policy changes everything: 400 TB/day raw media vs 30-day expiry is orders of magnitude in cost. Persistent connections are their own fleet problem.

Video streaming bandwidth and transcoding

Assumptions

Users2B total, 800M DAU

Watch time40 min/user/day

Bitrate5 Mbps (1080p adaptive)

Uploads500 hours/minute ingested

Calculations

1
Watch seconds / day
800M × 40 min × 60
→ 1.92T seconds/day
2
Concurrent streams (avg)
1.92T / 86,400
→ ~22.2M streams
3
Delivery bandwidth
22.2M × 5 Mbps
→ 111 Tbps → global CDN essential
4
Upload hours / day
500 hr/min × 60 × 24
→ 720K hours/day
5
Raw upload storage
720K hr × ~2 GB/hr compressed
→ ~1.44 PB/day
6
Multi-resolution
1.44 PB × 5 renditions
→ ~7.2 PB/day
7
Transcode servers
720K hr / 24 / 2 hr per server-hour
→ ~15,000 servers

111 Tbps

Delivery bandwidth

CDN mandatory

7.2 PB

Processed storage/day

5 renditions

~15K

Transcode fleet

2 hr video / server-hr

Architecture signal: delivery bandwidth dwarfs storage. Plan CDN PoPs and peering before optimizing transcode cost.

Capacity playbook: worksheets, servers, patterns, and cost

The worked examples show full narratives; this playbook is the reusable toolkit you apply next: million-user worksheets, server math with the , sanity thresholds, and rough cloud cost.

Million-user worksheets by workload

Use the same baseline unless the interviewer changes it: 1M , 20 actions/user/day, 5× , 80/20 read/write split, 85% cache hit ratio, 92% byte hit ratio, 120 safe per API replica, and p95 < 200 ms / p99 < 800 ms. Each worksheet turns a number into an architecture decision: cache, queue, object storage, partitioning, idempotency, or degraded mode.

Feed / timeline

Dimension	Formula	Sizing note
Traffic	1M DAU × 20 feed opens/day ÷ 86,400 × 5 peak	~1.2K peak read QPS
Fan-out reads	20 items/page × 1.2K peak QPS	~24K item lookups/sec before cache
Cache relief	85% cache hit on item/profile reads	~3.6K backend lookups/sec
Storage	240 write QPS × 1 KB × 86,400 × 3 replicas × 2 index factor	~124 GB/day provisioned growth

Chat / realtime

Dimension	Formula	Sizing note
Messages	1M DAU × 40 messages/day ÷ 86,400 × 5 peak	~2.3K peak message writes/sec
Connections	10% simultaneously connected	~100K live sockets
Fan-out	2 recipients average × 2.3K writes/sec	~4.6K delivery events/sec
Storage	40M messages/day × 500 bytes × 3 replicas × 1.5 index factor	~90 GB/day physical

Object storage / media

Dimension	Formula	Sizing note
Uploads	100K objects/day × 50 MB average	~5 TB/day raw payload
Derivatives	Raw payload × 60% derived renditions	~3 TB/day extra
Multipart calls	50 MB object ÷ 10 MB parts × 100K uploads × 1.05 retries	~525K part PUTs/day
CDN offload	92% byte hit ratio	Origin serves 8% of bytes plus cold-miss bursts

Notifications

Dimension	Formula	Sizing note
Events	1M DAU × 10 notifications/day	10M notification jobs/day
Peak send rate	10M ÷ 86,400 × 5 peak	~580 jobs/sec before fan-out
Worker count	580 jobs/sec ÷ 50 safe jobs/sec/worker × 1.3 headroom	~16 workers
Degraded mode	Provider outage queues work for 1 hour	~2.1M delayed jobs at peak

Rate limiter

Dimension	Formula	Sizing note
Request rate	1.2K peak QPS × 3 checks/request	~3.6K limiter ops/sec
Key memory	1M active keys × 100 bytes × 2 replicas × 1.5 overhead	~300 MB
Hot key	One actor at 10K req/sec, 2K safe ops/shard	Need at least 5 salted counters or local prefilter
Fallback	Limiter store down	Fail closed for abuse-sensitive routes; fail open for low-risk reads

Payments / search

Dimension	Formula	Sizing note
Payments writes	1M DAU × 0.2 payments/day ÷ 86,400 × 5 peak	~12 peak payment attempts/sec
Idempotency storage	200K attempts/day × 2 KB × 30 days × 3 replicas	~36 GB retained
Search reads	1M DAU × 5 searches/day ÷ 86,400 × 5 peak	~290 peak search QPS
Search index	100M docs × 2 KB × 1.5 index factor × 2 replicas	~600 GB index footprint

Interview tip: after each estimate, say the next engineering move. Example: "580 notification jobs/sec is fine for a small worker pool, but provider outages require queues, retries with jitter, and a backlog drain plan."

Server estimation and cache hit targets

Suppose a route receives 10,000 requests per second at peak and a load test shows that one replica safely serves 500 within the latency target. The serving requirement is twenty replicas. If any one of three equally sized zones must fail without overload, the two surviving zones together need all twenty, so deploy at least ten per zone, or thirty total, before accounting for uneven traffic and deployments.

Also estimate concurrency. With an average response time of 0.2 seconds at a stable 10,000 requests per second, Little’s Law gives about 2,000 requests in flight. That figure helps size bounded worker and connection pools; it is not a request-rate limit and should use a mean residence time rather than casually substituting p99.

With worksheet in hand, convert peak load into servers and cache size using the rules of thumb and multipliers below (peak and match Numbers to know above).

QPS capacity per server (rules of thumb)

Workload	Typical QPS
Simple API server	1K–10K QPS
With caching	10K–100K QPS
Static file serving	50K–200K QPS
Database (relational)	5K–20K QPS
In-memory cache	100K–500K ops/sec

1
Servers needed
Peak QPS ÷ QPS per server × (1 + buffer%)
→ Example: 100K / 5K × 1.3 = 26 servers
2
80/20 cache rule
Cache size ≈ 20% × daily unique data
→ 10M queries × 20% × 10 KB ≈ 20 GB

10×

90% hit rate

DB load reduction

20×

95% hit rate

DB load reduction

100×

99% hit rate

DB load reduction

Scaling multipliers to apply

3×

Replication

Data durability

2–3×

Peak vs average

Traffic shape

1.3–1.5×

Ops headroom

Deploy / failure buffer

1.2–1.5×

Yearly growth

Capacity planning

Common estimation patterns

Keep bytes and bits visible: 10,000 responses per second at 100 KB each produce about 1 GB/s, or 8 Gb/s, before overhead. If the CDN serves 90% of bytes, origin egress is about 0.1 GB/s, but its request hit ratio may be different. A large video miss contributes far more bandwidth than a tiny image miss, so choose the ratio that matches the resource being estimated.

For storage, distinguish new logical bytes from retained physical bytes. At 100 GB/day and a 30-day retention window, live logical data is about 3 TB. Three copies make 9 TB before indexes, compaction space, metadata, and backups. Retaining every historical version or a year of backups can dominate the live dataset even when primary retention is short.

Patterns and sanity checks catch order-of-magnitude mistakes before you commit to a fleet size or a cutover.

QPS from DAU

plaintext

QPS = (DAU × actions_per_user) / 86,400

Peak ≈ 2–3× average

Storage from write rate

plaintext

writes/day × size × retention × replication

Include indexes and metadata overhead

Bandwidth from QPS

plaintext

QPS × avg_response_size

1 Gbps = 125 MB/s

Servers from QPS

plaintext

peak_QPS / QPS_per_server × 1.3

30% buffer for deploys and spikes

Cache size (80/20)

plaintext

unique_daily_items × 20% × avg_size

Cache top 20% → serve ~80% of traffic

Sanity checks → architecture

Threshold	Implication
> 1 PB storage	Distributed object / file storage
> 100K QPS	Sharding or aggressive caching
> 10 Gbps bandwidth	CDN near users
> 100 servers	Container orchestration
> $1M/month	Re-check assumptions and retention

Quick unit checks

Conversion	Value
1 TB	1,000 GB
1 PB	1,000 TB
1 Gbps	125 MB/s
10 Gbps	1.25 GB/s
1M req/day	~12 QPS
1B req/day	~12K QPS
100B req/day	~1.2M QPS

Cost estimation at scale

Capacity without cost is incomplete: the photo and messaging figures from the worked examples above show how retention and dominate the bill.

Cloud list-price reference points (approximate)

Resource	Approximate cost
EC2 m5.xlarge (4 vCPU, 16 GB)	~$140/mo on-demand, ~$85 reserved
RDS db.r5.xlarge	~$350/mo on-demand
Object storage	$23/TB/month (standard)
Object GET requests	$0.005 / 1K reads
Object PUT requests	$0.05 / 1K writes
CDN bandwidth	~$0.085/GB (first 10 TB/mo)
Managed cache node	~$250/month
Managed KV writes/reads	$1.25M / $0.25M per million

Large photo service (annual)

1
Raw storage
150 TB/day × $23/TB × 12
→ ~$497M/year
2
With tiering
~60% savings
→ ~$200M/year storage
3
CDN
600 Gbps peak delivery
→ ~$4M/month
4
Compute
500 × $140/mo servers
→ ~$70K/month

The approximately $220M/year total below is an illustrative result of the assumed stored bytes, replicas, and unit prices. Treat the unit prices as worksheet inputs rather than current quotes. Change retention, compression, and replication separately to identify the dominant cost driver; a price calculation is useful when it explains which product or architecture choice changes the bill.

Large messaging (annual)

1
Raw media storage
400 TB/day × $23/TB × 12
→ ~$1.1B/year
2
30-day retention
Lifecycle expiry
→ ~$12M/year
3
Connection fleet
10K × $140/mo
→ ~$1.4M/month

The approximately $30M/year example depends on the assumed traffic, retention, and unit prices. Expiring messages reduces retained storage, but does not remove ingestion, indexing, replication, or delivery costs already incurred. Price each major resource with its own unit and use the selected provider’s current rates when turning this worksheet into a budget.

Cost pitfalls: forget 3× replication, ignore egress/transfer, use on-demand pricing only, skip dev/staging overhead (+20–30%), and under-budget logging/backups.

What still breaks after you estimate carefully

Even with Numbers to know and the playbook above, these capacity-planning mistakes still ship bad designs. Treat them as the failure modes to name in an interview.

Using average instead of peak

Average 10K QPS → peak ~30K with a 3× multiplier. Size for peak × 1.3 headroom, not the daily average.

Forgetting metadata

1B photos may be 1.5 PB of blobs but hundreds of GB–TB of metadata, indexes (2–3×), and fast lookup paths.

Ignoring read amplification

One API request can become 5 DB queries. 10K user QPS → 50K DB QPS is common (3–10× factor).

Not modeling write amplification

LSM stores: 10–30× write amplification. 1 GB of logical writes can mean 10–30 GB of disk I/O.

Linear growth assumption

Viral products grow faster than linear. Plan 2–3× yearly and review capacity quarterly.

Choosing and explaining back-of-the-envelope estimation

A complete explanation connects the mechanism to a requirement. Describe what improves when you introduce it, which new failure cases become possible, and how you would know that the trade-off is worthwhile.

Explain the core idea

Start from user behavior, not infrastructure guesses.

Convert daily totals to QPS with 86,400 seconds/day, then apply peak and headroom.

Translate numbers into design choices: cache, CDN, sharding, queues, storage tiering, and cost.

When it belongs

Before choosing databases, caches, queues, or CDNs.

When a design decision depends on whether traffic is 1K QPS or 1M QPS.

When the interviewer asks capacity, storage, bandwidth, or server count.

How it fails

Averages hide peak traffic and regional hotspots.

Ignoring read/write amplification overloads databases.

Storage estimates miss replication, indexes, retention, and backups.

Trade-offs to weigh

Rough math is fast but must be checked with monitoring after launch.

Overprovisioning buys safety but raises cost.

Aggressive retention improves product value but dominates storage cost.

Common misunderstandings

Jumping to microservices before sizing the workload.

Mixing bits and bytes in bandwidth calculations.

Giving exact-looking numbers without stating assumptions.

Try it: back-of-the-envelope capacity sketch

Adjust users, daily actions, payload size, and a peak multiplier. The lab derives average and peak request rates plus rough bandwidth and yearly storage growth so you can sanity-check a design in an interview.

Monthly active users5,000,000Actions per user per day4Bytes per action (write payload)2,048 BPeak multiplier over daily average×3

Average RPS: 231.5
Peak RPS: 694.4
Peak egress (Mb/s): 11.4
Daily write volume: 40.96 GB
Rough yearly raw growth: 14.95 TB

At 5,000,000 users, average load is about 231.5 requests per second and peak (×3) is about 694.4 RPS. Steady egress at peak is roughly 11.4 Mb/s if each action moves 2048 bytes.

Going deeper

Back-of-envelope sizing

The mechanism and its boundary

Fast sizing turns vague scale into design constraints. The goal is not perfect accounting; it is to catch impossible assumptions early and show which dimension drives the architecture.

Estimate funnel

Users

QPS

Storage

Bottleneck

Work through the sizing assumptions

Convert users to requests: 50M daily active users * 20 actions/day = 1B actions/day, about 11,600 average requests/sec before peak multiplier.

Apply peak factor: if peak is 10x average, design for 116,000 requests/sec plus headroom.

Storage: 10M uploads/day * 2 MB = 20 TB/day; with 3 copies that is 60 TB/day raw.

When it belongs

The interviewer gives users, reads, writes, storage, or latency goals. You need to choose between single-node, sharded, cached, or streamed designs. A bottleneck is unclear and needs a first-order estimate.

Assumptions that matter

Daily traffic is uneven and usually needs a 5-20x peak multiplier. Replication multiplies raw storage and network traffic. Hot keys and celebrity users break uniform distribution assumptions.

Easy mistakes

Daily average traffic understates busy periods and may hide regional imbalance, so state the assumed peak and test what happens when one region absorbs another’s load. Stored payload bytes are only a starting point: replicas, indexes, compression, retention, and temporary rebuild copies change the physical capacity needed. Bandwidth calculations must convert bits to bytes explicitly and name decimal or binary units, or a plausible-looking estimate can be wrong by a large factor.

How it fails

Underestimated fanout makes the write path explode. Storage growth exceeds compaction or backup bandwidth. Cache memory is sized for values but not metadata and overhead.

Trade-offs to name

Rough arithmetic quickly identifies whether memory, bandwidth, or request throughput dominates, but the riskiest assumption still needs a measured limit or a sensitivity calculation. Extra capacity provides room for uncertainty and failover, but cannot efficiently solve a single hot key or an unsuitable access pattern, so inspect the busiest resource as well as fleet totals. Per-user averages make an initial model easy to compute, while peak factors and a separate heavy-user example reveal the skew that the average hides.

Wrap-up

You have seen the path from users to architecture, the constants to memorize, and the pitfalls that still bite. Use the references below as primary sources, then keep the takeaway as your default interview habit.

Topic-specific references

Latency Numbers Everyone Should Know : canonical latency table behind the hierarchy in Numbers to know.
Google SRE Workbook: Alerting on SLOs : capacity signals tied to user pain rather than raw utilization.
Dean & Barroso: The Tail at Scale : why averages mislead sizing and why p99 matters.

Key takeaway

Memorize the key numbers: latency hierarchy (1ns / 100ns / 100μs / 10ms), powers of 2, and 86,400 seconds/day. A large photo feed can need ~150 TB/day. A large messaging system can handle ~230K messages/sec. A large video service can require 111 Tbps for delivery. The means caching 20% of data serves 80% of traffic. Always state assumptions, use round numbers, and show your reasoning: "roughly 1 PB" beats "I'd need to measure."

Practice and further reading

Use these exercises to connect the lesson to a design decision. State your assumptions, trace what happens to one request, and explain the rule that must remain true even during a failure. That rule is the design's correctness invariant.

Focus for this lesson: Estimate peak QPS, storage, bandwidth, memory, fan-out, replication, headroom, and cost with units, ranges, dated assumptions, and sensitivity checks.

Explain the decision

What makes an estimate useful rather than precise-looking?

Read the reasoning

Units and assumptions are explicit, order of magnitude is checked, peak/headroom and amplification are included, and the result changes a design decision.

Apply it to a production scenario

Compression could be 2x to 8x. How do you present storage?

Read one approach

Show a range/sensitivity table and design against a conservative case until representative measurements replace the assumption.

Work through the numbers

500M events/day × 1.2 KiB × 30 days × 3 replicas equals roughly what?

Read the worked calculation

About 49.1 TiB using binary units, before indexes, compaction, metadata, and backups.

Reason through a failure

What must every estimate review catch?

Read the recovery reasoning

Unit mismatch, average used as peak, omitted replication/indexes/retries, impossible utilization, and a result that never feeds a decision.

Sources and further study

Continue with Circuit Breaker Pattern.