System design · Module 03 of 29 · Level 1: Foundations

Back-of-the-envelope estimation

Before choosing a database or adding a cache, you need to know roughly how much traffic and data you're dealing with. Not to the last request: to the nearest power of ten. Ten minutes of rounded arithmetic tells you whether one server is plenty or whether you need a fleet, and it stops you building machinery a problem doesn't need.

New to this?Start with B6 · From one server to millions in Level 0; this module assumes it.

1. The idea

Planning a party for 60 people, you don't count slices. You think: about three slices each, eight slices a pizza, so roughly 20–25 pizzas, and one oven can't bake that in an hour, so order from two shops. Rough numbers, one clear decision. That's a back-of-the-envelope estimate.

An estimate turns a vague description ("a photo app for 50 million people") into four numbers that drive design decisions:

Requests per second, on average and at peak, split into reads and writes. This decides how many servers, and whether you need a cache.
Storage per day and over the data's lifetime. This decides whether one database fits, and where big files go.
Bandwidth: bytes per second going out to users. This decides whether you need a CDN.
Memory for the hot data. This decides whether the working set fits in one cache.

The trick that makes it fast: round everything to one significant figure and work in powers of ten. A day has 86,400 seconds; call it 10⁵. You'll be off by about 15%, which never changes a design decision.

Power	Count	Bytes	Handy facts
10³	thousand	KB	A short text record with a few fields: hundreds of bytes to ~1 KB
10⁶	million	MB	A phone photo: ~2–5 MB original, ~100–300 KB resized for display
10⁹	billion	GB	A minute of 1080p video streamed at 5 Mbit/s: ~40 MB
10¹²	trillion	TB	A large single database: tens of TB
10¹⁵	quadrillion	PB	Big video and photo platforms store many PB in blob storage

Time conversions to know by heart: 1 day ≈ 10⁵ s · 1 month ≈ 2.5 × 10⁶ s · 1 year ≈ 3 × 10⁷ s. So 1 million per day ≈ 12 per second, and 1 billion per day ≈ 12,000 per second.

2. How it works

The same recipe works for almost any system. Press Play to watch it on a photo-sharing app with 50 million daily active users.

Every line ended in a decisionThat's the point. "29,000 reads per second" is trivia; "so we need a cache in front of the database" is design. If a number wouldn't change what you build, you don't need to calculate it.

The recipe

Users: daily active users (DAU). If you're given monthly users, DAU is often 20–50% of that.
Actions: reads and writes per user per day. Most products are read-heavy: 10:1 to 100:1.
Per second: per day ÷ 10⁵.
Peak: × 2–3 for a normal daily peak; × 10 or more for launches, sales and live events.
Storage: writes per day × bytes each × days kept. Multiply by about 3 for replicas, and add room for indexes.
Bandwidth: read QPS × response size. Watch bits vs bytes: 1 GB/s = 8 Gbit/s.
Verdict: compare each number with what one machine can do (Module 02) and say what it means for the design.

3. Try it yourself

Estimation calculator

Pick a preset or type your own numbers. The verdicts compare each result with rough single-machine limits from Module 02.

Conversion drill

Speed comes from practice. Answer in your head, then reveal. Aim for the right power of ten in under ten seconds.

4. Trade-offs

Speed over precision

One significant figure is enough. Spending ten minutes getting 11,574 instead of "about 10,000" costs you time and changes nothing.

State your assumptions

"I'll assume 50M daily users, each viewing 50 photos." Saying it lets others correct you early, and makes the result easy to redo when the assumption changes.

Only calculate what decides something

In an interview, skip a long estimate up front. Do the math at the moment it matters: "Does the top-K fit in one machine's memory? 10M items × 100 bytes = 1 GB, yes."

Peak and growth, not just today

Systems fail at peak, not on average, and data only grows. Estimate the peak, and the size in a few years, before deciding one machine is enough.

5. In real systems

At work, the same arithmetic becomes capacity planning:

Start with an estimate, then measure. A load test (with tools such as k6, Locust, Gatling or JMeter) tells you what one server really handles for your requests. The estimate tells you how many of those you'll need.
Plan for peaks and failures. Size so that at peak, with one server or one zone lost, the rest still run below ~70% (Module 02's headroom).
Watch the growth curve. Storage grows every day; requests grow with users. A design that fits today but hits a limit in 18 months needs a plan now, not code now.
Estimate cost the same way. Instance-hours, GB stored and GB transferred out, each times a price from the provider's pricing page. Data transfer out to the internet and cross-region traffic are the costs people most often forget.

Sizes worth memorising: an ID or timestamp 8 bytes; a UUID 16 bytes (36 as text); a typical row of user content a few hundred bytes to 1 KB; a resized image 100–300 KB; video at a few Mbit/s, or tens of MB per minute.

The numbers up close

The default answer in an interviewWrite each estimate as a chain with units: 100 million users × 10% daily active × 20 reads = 200 million reads a day ≈ 2,300 a second, ≈ 7,000 at peak. Round freely, then say what the number decides: one machine or many, cache or not, database or object storage, affordable or not.

Powers of two and the units that trip people up

Know by heart

Most estimation slips are unit slips: bits vs bytes, thousand vs 1,024, per day vs per second. A small table removes them.

How it works

Power	Exact	Think of it as	Where it shows up
2¹⁰	1,024	a thousand (KB)	KiB vs KB: disks are sold in 1,000s, memory counted in 1,024s
2²⁰	1,048,576	a million (MB)
2³⁰	≈ 1.07 billion	a billion (GB)
2³¹ − 1	2,147,483,647	2.1 billion	The largest signed 32-bit integer: a 32-bit ID column overflows here
2³²	≈ 4.3 billion	4 billion	All IPv4 addresses; unsigned 32-bit values
2⁴⁰ / 2⁵⁰	≈ 1.1 × 10¹² / 10¹⁵	TB / PB
2⁶⁴	≈ 1.8 × 10¹⁹	effectively unlimited	64-bit IDs never run out

Time: a day is 86,400 s ≈ 10⁵; a month ≈ 2.6 million s; a year ≈ 3.15 × 10⁷ s. So 1 million a day ≈ 12 a second, 1 billion a day ≈ 12,000 a second.
Bits vs bytes: networks are quoted in bits. A 10 Gbit/s link moves about 1.25 GB/s, before overheads.
Base-62 and base-64: 62⁷ ≈ 3.5 trillion, which is why a 7-character short URL is plenty (Design D01).

Status today

Timeless. Interviewers accept rounding (86,400 → 100,000) as long as you say you're rounding.

Use it when

Every estimate: say the unit out loud at each step

Skip it when

Precision beyond the first digit: it changes no decision

In the interview

A billion requests a day is about 12,000 a second on average; at 3× peak, roughly 35,000.

🚩 Red flags

Mixing Gbit and GB (an 8× error).
32-bit IDs for a table that will pass 2 billion rows.

Storage maths, end to end

The default storage estimate

Raw data is only the start. Real storage is raw size times replication, times index and format overhead, over the retention period, plus backups.

How it works

Total ≈ items a day × size × 365 × years × replicas × overhead. Typical multipliers: 3 replicas (or about 1.5× for erasure-coded object storage), 1.3–2× for indexes, padding and free space in databases, and backups on top. Try a photo app:

Status today

Object stores (S3, Cloud Storage, Azure Blob) handle replication for you: S3 Standard, for example, stores data across at least three Availability Zones. You pay for the logical bytes; the provider absorbs the redundancy.

Use it when

Every design with user content, logs or events
Deciding between one database, sharding, or object storage plus metadata

Skip it when

Small metadata tables (a few GB): say "fits on one machine" and move on

In the interview

10 million photos a day at 300 KB is 3 TB a day, about 1 PB a year: object storage for the files, and only the metadata in the database.

🚩 Red flags

Forgetting replication and indexes, so the database is undersized by 3–6×.
No retention policy: logs and events kept forever by default.

Cloud cost, roughly

Situational · when cost comes up

Cost is three meters: compute hours, storage per GB-month, and data moved (especially out to the internet). A few list prices let you sanity-check a design in an interview.

How it works

Item (AWS US East, on-demand list price)	Price	Rough feel
General-purpose VM, 2 vCPU / 8 GB (m7g.large)	≈ $0.08 an hour	≈ $60 a month
S3 Standard storage	$0.023 per GB-month	1 PB ≈ $23,000 a month
S3 Glacier Deep Archive	$0.00099 per GB-month	about 23× cheaper; hours to restore
S3 requests	PUT $0.005, GET $0.0004 per 1,000	a billion GETs ≈ $400
Data out to the internet	≈ $0.09 per GB (first 100 GB a month free)	1 PB served from origin ≈ $90,000
Between regions	≈ $0.01–0.02 per GB	replication across regions adds up

Other clouds are in the same range. Discounts (reserved or savings plans, spot, committed CDN contracts) commonly cut list prices by a third to well over half.

Status today (checked October 2026)

Prices checked October 2026 on the providers' pricing pages; they change, so treat them as orders of magnitude.

Use it when

The interviewer asks about cost, or two options differ mainly in cost
Video, backups, logs or AI inference: workloads where cost decides the design

Skip it when

Exact quotes: one significant figure is enough

In the interview

Serving 1 PB a month straight from S3 would be about $90K in egress alone, so video goes through a CDN, and cold originals move to an archive tier after 30 days.

🚩 Red flags

Ignoring data transfer out, often the largest line for media.
Millions of tiny objects where request fees exceed storage fees.
Cross-region replication of everything without asking what really needs it.

Estimate against a threshold, in ranges

The default · every estimate

An estimate only matters next to the number that would change your design: the memory of one cache node, the writes one primary can take, the budget per user. Inputs in an interview are guesses, so give each one a low and a high value and see where the whole range lands against that threshold.

How it works

Name the decision and its threshold. "Does the hot set fit in one 256 GB cache node?"
Give each input a range you'd defend: 2–6 million daily users, 30–80 items each, 300–800 bytes per item.
Multiply the lows and the highs. 18 GB to 384 GB.
Read the answer off the threshold. Entirely below: decided, move on, and say the uncertainty didn't matter. Entirely above: decided the other way. Straddling: the estimate's real output is which input to measure, the one with the widest spread.

Try it: change the ranges and the threshold, and watch the verdict.

Status today

Ranges are what planners do at work too: a forecast with a low and a high case, compared against what the current design can carry.

Use it when

Any estimate that decides one machine or many, cache or not, affordable or not

Skip it when

Numbers that don't change the design: if more servers fix it, skip the arithmetic

In the interview

Between 18 and 384 GB, against a 256 GB node, so it depends almost entirely on daily users. I'll design for the high case and confirm that one number first.

🚩 Red flags

A single number to four digits from inputs that are guesses.
An estimate with no threshold: arithmetic that decides nothing.

Catching the factor-of-1,000 mistake

The default · ten seconds per estimate

Estimation errors are rarely 20%. They are a lost "per second" or a megabyte read as a kilobyte, which makes the answer 1,000 times wrong. Four quick checks catch nearly all of them.

How it works

Check	What you do	What it catches
Carry the units	Write units next to every number and cancel them: requests/s × KB/request = KB/s	Answers in the wrong unit; a day silently treated as a second
Picture it	Turn the result into something physical: one laptop's memory, one disk, a rack, a warehouse	Results that "look fine" until you see they need 4,000 disks
Run it backwards	From the result, recompute one input and see if it matches what you assumed	Dropped or doubled powers of ten
Compare with something known	Hold it against a public figure: Wikipedia's size, a known service's traffic	A chat app for one school needing more storage than YouTube

Worked slip: "A fitness app stores 2 KB per workout, 5 million workouts a day, so 10 GB a second." Carry the units: 5M workouts a day × 2 KB = 10 GB a day, about 115 KB a second. The slip changed the answer from "a big cluster" to "one modest database".

Status today

The same checks are taught in physics as dimensional analysis and order-of-magnitude reasoning; they work just as well on servers.

Use it when

Every estimate you say out loud
Reviewing someone else's capacity plan

Skip it when

Nothing: it takes seconds

In the interview

10 GB a day, so about 120 KB a second: one database handles that easily, even at five times the peak.

🚩 Red flags

No units on the board.
Not noticing a result that implies more hardware than the whole company could own.

A capacity plan in five lines

The default · when the interviewer asks "how many servers?"

How many machines is not traffic ÷ capacity. You plan for the busiest window you expect, keep room for a failure, add the growth until the next review, check which resource runs out first, and round up to whole machines.

How it works

Line	Question	Ticket-resale API, worked
1. The peak	Which window? The busiest few minutes of the busiest day this quarter, not the daily average	900 requests a second, during a big on-sale (the average is 150)
2. Growth	How far ahead, at what monthly growth? Compounding: 8% a month is 1.6× in six months	6 months × 8% → 1.59 × 900 ≈ 1,430 a second
3. Per machine	What one machine does at a safe load (measured, about 70% of its limit, since latency climbs fast above that: Module 02)	250 a second each
4. Losing a zone	Spread over N zones; if one fails, the rest carry everything: plan for N ÷ (N − 1)	3 zones → × 1.5 → 1,430 ÷ 250 × 1.5 = 8.6
5. Round up, per resource	Whole machines, split evenly across zones; check memory, connections and disk too	9 machines, 3 per zone. Memory is at 40%, so CPU is the limit

What autoscaling won't do for you: new machines take from tens of seconds to minutes to start and warm up. The first minutes of a sudden spike land on the machines already running, so the floor still needs the plan above. And scaling the app tier when the database is the limit adds connections to the thing that's already full.

Status today

Cloud providers spread regions across three or more zones, which is why N ÷ (N − 1) with N = 3 (that is, 1.5×) is the usual failure headroom.

Use it when

"How many servers?" in an interview
Before a launch, sale or season with a known date

Skip it when

Serverless or fully managed parts priced per request; plan their limits and quotas instead

In the interview

About 1,400 a second at the busiest moment six months out; at 250 per machine and surviving a zone loss, that's 9 machines, 3 per zone, with CPU as the limit.

🚩 Red flags

Sizing for the average.
Running at 95% "to save money", where every request waits in line.
"Autoscaling handles it" for a spike that arrives in seconds.

Cost per request, per user, and the line that dominates

Situational · when cost decides

The prices in the block above become useful once you turn them into a cost per request or per user and compare it with what a request or user earns. Usually one line is far bigger than the rest, and that's the only one worth designing around.

How it works

A photo app's feed: each feed load returns about 1.2 MB of images and needs some compute and a few database reads.

Line	Working	Per million feed loads
Compute	A $0.08-an-hour machine serves 300 loads a second, about 1.1 million an hour	≈ $0.07
Database	Say five times the compute bill	≈ $0.40
Data out	1.2 MB × 1M = 1,200 GB × $0.09	≈ $108

Data out is over 200 times everything else together. Per user: 40 feed loads a day is 1,200 a month, 1.4 GB, so about $0.13 a month at list price. If an average user brings in $0.10 a month, the design loses money on every user before anyone is paid. The fixes are in the data-out line, and each has a different owner: fewer bytes (images sized to the screen, modern formats), a lower price per byte (a CDN contract at volume), and fewer loads (cache on the device: a product decision as much as a technical one).

Two other lines grow quietly: storage after copies (replicas, backups and logs multiply the logical size), and monitoring, whose metric cost grows with the number of distinct label values, not with traffic.

Status today

Prices are AWS US East list prices, checked October 2026; data out to the internet is $0.09 per GB for the first 10 TB a month and falls to $0.05 above 150 TB. Treat them as orders of magnitude.

Use it when

Media, downloads, AI inference, logging: anything where bytes or tokens dominate
Comparing two designs that both work

Skip it when

Typical CRUD APIs where the bill is small next to salaries; say so in one line

In the interview

Data out is the whole bill: about 11 cents per thousand loads against well under a cent for compute. So images go through a CDN and are sized to the screen, and I'd ask the product team about caching the feed on the phone.

🚩 Red flags

Optimising compute when data out is 100× larger.
Cost never compared with revenue per user or per request.

Four estimates that change a design

The default · the ones worth doing

Most interview estimates confirm what you'd build anyway. These four kinds regularly overturn a design in under a minute, so they're worth doing whenever they apply.

How it works

Question	Quick number (our examples)	What it changed
Does it fit where you're putting it?	A music app precomputes daily mixes for 80M users. 50 track IDs × 16 bytes = 64 GB in total: fits in memory. Storing each track's full details (2 KB) in every mix: 8 TB	Store IDs only and look details up from a shared cache
Does the fan-out finish in time?	A school-closure alert to 3M parents within 2 minutes needs 25,000 sends a second; the SMS provider allows 5,000, so it takes 10 minutes	Send to app users by push first, buy more SMS throughput, or agree on a 10-minute target
Does the cost fit the revenue?	$0.13 of data out per user per month against $0.10 of revenue (the block above)	CDN, smaller images, caching on the device
Does the build finish before the growth arrives?	Writes grow 12% a month, so they double in about 6 months; the primary is at half its limit; splitting the database takes about 9 months	The project starts now, or the cheaper stopgaps (tuning, a bigger machine) are scheduled to cover the gap

Status today

All four come up in real design reviews as much as in interviews: memory fit, fan-out time, unit economics and lead time.

Use it when

When a proposed design sounds plausible but rests on one big quantity

Skip it when

Quantities that only change the number of identical machines

In the interview

Before we go further: 3 million texts at 5,000 a second is 10 minutes, so either the target changes or the sending path does.

🚩 Red flags

Estimating everything up front and then designing as if you hadn't.
Treating today's load as the planning load when growth is fast.

6. Remember it

Memory hook: "A day is a hundred thousand seconds"Per day ÷ 10⁵ = per second. Then × peak, × bytes, and finish every number with "so we need…".

How this hook works: what "A day is a hundred thousand seconds" means

What the slogan means

"A day": Products are described per day (users, posts, views), but servers are sized per second. The day is the bridge.
"a hundred thousand seconds": 86,400 rounded to 10⁵. Dividing by a power of ten is something you can do instantly in your head: 3 billion a day is 30,000 a second.
(and what it implies): The rounding is deliberate. Estimates aim for the right power of ten, not the right digits.

Why this picture fits: it's the one conversion you'll use in every estimate, and it carries the whole method in it: round boldly, convert, then decide.

The story → the concept

Step	What you write
Per day	DAU × actions per user
÷ a hundred thousand	Average per second
× peak factor	The number you size for
× bytes × days	Storage and bandwidth
"so we need…"	The design decision

Watch it on an example

A chat app: 200M daily users, each sending 40 messages a day.

Per day: 200M × 40 = 8 × 10⁹ messages.
÷ 10⁵ = 80,000 messages per second on average; × 3 at peak ≈ 250,000 per second.
× 200 bytes ≈ 1.6 TB of new messages a day; ≈ 600 TB a year before replication.
So we need: a write-optimised store split across many machines, and connection servers for the live traffic. One relational database won't do.

The trap it saves you from

Either extreme: designing a planet-scale system for 10,000 users, or putting 250,000 writes per second on one database. Ten seconds of arithmetic tells you which world you're in.

It still works when…

The unit isn't requests: GPU-seconds per day for an AI feature, emails per day, sensor readings per day. Per day ÷ 10⁵ still gets you to "per second", which is what machines are sized by.

7. Common mistakes

Estimating without concludingA page of numbers that doesn't end in "so we need X" or "so one database is fine" has wasted the time. Every number should change or confirm a decision.

Sizing for the averageTraffic peaks at 2–3× the daily average, and much more during events. Size for the peak.

Mixing up bits and bytesNetwork speeds are in bits (Gbit/s), storage in bytes (GB). 1 GB/s of video out is 8 Gbit/s of network.

Forgetting replicas, indexes and metadataRaw data × 3 replicas, plus indexes, plus backups, is easily 4–5× the raw number.

False precision"11,574.07 requests per second" suggests accuracy the inputs don't have. Say "about 10,000" and move on.

8. Design exercise (25 minutes)

URL shortener. 100M new links a month, read 100 times each on average, kept for 10 years, ~500 bytes per link. Estimate write QPS, read QPS at peak, and total storage. Does it fit one database?
Ride hailing. 5M drivers online at peak, each sending a location every 4 seconds. Estimate writes per second. What does that number rule out?
Video platform. 500 hours of video uploaded per minute, stored in 4 resolutions averaging 1 GB per hour each. Estimate storage per day and per year.
Check yourself. Put each into the calculator above (adjust the presets) and compare.
Write it down. In your design notebook: the three conversions (day, month, year) and the bits/bytes rule.

9. Self-check quiz

About how many requests per second is 1 billion requests per day?

10⁹ ÷ 10⁵ = 10⁴. The exact figure is 11,574, but "about 10,000" leads to the same design.

A service sends 10 GB per second to users. What network capacity is that?

Multiply bytes by 8 for bits: 10 GB/s = 80 Gbit/s. That's a strong hint you need a CDN.

When is it worth doing an estimate in an interview?

Do the math at the moment it decides something: whether data fits in memory, whether one database can take the writes.

What should you size servers for?

Failures happen at peak. Size for peak load running at ~50–70% utilization, so you can absorb spikes and lose a machine.

A 10 Gbit/s network link moves about how many gigabytes a second?

Divide bits by 8. Network speeds are quoted in bits.

Serving 1 PB a month directly from object storage to users costs roughly what in data transfer at list price?

About $0.09 per GB × 1,000,000 GB. That's why media goes through a CDN.

Your estimate of a cache's size runs from 40 GB to 600 GB, and one node holds 256 GB. What's the most useful next step?

When a range straddles the threshold, the estimate's job is to point at the one input worth measuring.

Peak is 1,200 requests a second, one machine safely does 200, and you run in 3 zones. How many machines?

1,200 ÷ 200 = 6 for the load; surviving the loss of one of 3 zones needs × 1.5 = 9, three per zone.

A media feed's data out costs 200× its compute. Where should the design effort go?

Design around the line that dominates; shaving the small lines changes nothing.

10. Go deeper

Resource	Time	Why
napkin-math (Simon Eskildsen)	1 hour	Measured numbers plus a set of practice estimation problems with solutions.
Back-of-the-envelope estimation (ByteByteGo)	15 min	A concise chapter with a worked example and estimation tips.
Numbers to know (Hello Interview)	20 min	Modern single-machine limits, and the over-engineering mistakes they prevent.
System Design Primer: back-of-the-envelope calculations	10 min	Powers of two, latency numbers and handy conversions on one page.