Back-of-Envelope Numbers Every Architect Should Have Memorized

Every system design post on this blog has a step that says “do the math.” This is the page with the numbers that step depends on. Memorize the ones in bold, know the rest to within a factor of ten, and you will never again stand at a whiteboard unable to say whether the thing you just drew fits on one machine or a thousand.

Estimation in an interview is not about precision. It is about getting the order of magnitude right fast enough that it changes what you draw next. A candidate who says “roughly 400 writes per second, so one database is fine, and the real problem is the read path” has made a design decision. A candidate who says “we would need to look at the numbers” has not.

Where This Shows Up

You will be asked to estimate, directly or indirectly, in every design question:

• “How much storage will this need in five years?”
• “How many servers is that?”
• “Does this fit in one database?”
• “What does that cost per month?”
• “Can the cache hold the working set?”
• “What is the peak, not the average?”

And the indirect form: you draw something, and the interviewer asks “would that work?” The only way to answer is with a number.

What They Are Really Checking

1. Can you convert a product statement into a rate? “Ten million daily users” means nothing until it becomes requests per second.
2. Do you know the order of magnitude of common things? How long a disk seek takes, how many requests a server handles, what a gigabyte of object storage costs. Not exact, but not off by a thousand.
3. Do you draw a conclusion from the number? The number is not the answer. “Therefore one node is enough” or “therefore we must shard” is the answer.
4. Do you separate peak from average? Most real outages happen at the peak. A design sized to the average is a design that fails on schedule.
5. Do you state your assumptions? “Assume 500 bytes per record” is a fine assumption. Silently using it is a mistake.

The Gotchas

Gotcha 1: False precision. “That is 86,400 seconds times 11.57 requests per second.” Nobody cares. Round aggressively: a day is 100,000 seconds, a million a day is about 10 per second. Precision slows you down and signals that you are computing instead of reasoning.

Gotcha 2: Forgetting the peak. Average is what you compute; peak is what you design for. Multiply by 2 to 3 for a normal daily curve, by 10 for spiky workloads, and say which one you are using.

Gotcha 3: Forgetting replication and indexes. The raw data is 1 TB. With a replication factor of 3 and index overhead, provision 4 TB. Candidates who forget this under-size storage by a factor of three or four.

Gotcha 4: Mixing bits and bytes. Network is measured in bits per second. Storage is measured in bytes. A 10 gigabit link moves about 1.25 gigabytes per second. Get this wrong once and the interviewer will double-check every other number.

Gotcha 5: Estimating things that do not matter. If the question is a URL shortener, the storage estimate takes ten seconds and the conclusion is “trivial.” Spend the time on the read rate. Estimate the dimension that will drive a decision.

Gotcha 6: Not saying the assumption. “Each message is about 100 bytes” is an assumption the interviewer can correct. “It comes to 2 TB” is a number they cannot check.

Gotcha 7: Stopping at the number. Always finish with “so.” “So this fits in memory on one node.” “So we need roughly forty application servers at peak.” The “so” is the entire point.

The Numbers

Prices are 2026 on-demand ballparks for the major clouds and move over time. Everything else is stable enough to memorize.

Powers of two and units

Power	Approximate	Unit	Rule
2^10	thousand	KB	Use 1,000, not 1,024, in interviews
2^20	million	MB
2^30	billion	GB
2^40	trillion	TB
2^50	quadrillion	PB

One byte per ASCII character, up to four bytes per UTF-8 character, about six bytes per English word including the space.

Time

Conversion	Value	Memorize as
Seconds per day	86,400	~100,000
Seconds per month	2.6 million	~2.5 million
Seconds per year	31.5 million	~30 million
1 million per day	11.6 per second	~10 per second
1 billion per month	385 per second	~400 per second
1 per second	86,400 per day	~2.6 million per month

The single most useful conversion: a million a day is about ten a second. Everything else scales from it.

The latency ladder

These are the classic “latency numbers every programmer should know,” updated for current hardware. The exact values matter less than the ratios. Each row is roughly ten to a thousand times the one above it.

Operation	Time	Memorize as
L1 cache reference	1 ns
Branch mispredict	3 ns
L2 cache reference	4 ns
Mutex lock and unlock	20 ns
Main memory reference	100 ns	memory: 100 ns
Compress 1 KB (fast codec)	2 µs
Send 1 KB over a 10 Gbps link	1 µs
Read 1 MB sequentially from memory	10 µs
Random read from NVMe SSD	20 to 100 µs	SSD: 100 µs
Read 1 MB sequentially from SSD	0.3 to 1 ms
Round trip inside one data center	0.5 ms	same DC: 0.5 ms
Disk seek (spinning disk)	5 to 10 ms	HDD: 10 ms
Read 1 MB sequentially from spinning disk	10 to 20 ms
Round trip across a continent (US coast to coast)	60 to 80 ms
Round trip across an ocean	100 to 150 ms	cross-region: 100 ms
Round trip US to Asia	150 to 200 ms

The ladder in five rungs: memory 100 ns, SSD 100 µs, same-DC network 0.5 ms, spinning disk 10 ms, cross-region 100 ms. Each rung is roughly a thousand times the previous one. That single fact explains most architecture: caches exist because memory is a thousand times faster than SSD, and multi-region is hard because a cross-region call costs a thousand SSD reads.

Throughput per node

Rules of thumb for one reasonably provisioned machine or managed instance. Real numbers vary by an order of magnitude with hardware and workload, so state your assumption and be conservative.

Component	Rule of thumb	Note
Stateless app server	1,000 to 10,000 requests/s	1,000 for real work per request, 10,000 for trivial handlers. Use 1,000 to be safe
Relational database (single primary)	Thousands of writes/s, tens of thousands of point reads/s	Say “about 10,000 mixed QPS” and shard for writes before storage
In-memory cache (Redis-class)	100,000 ops/s	Up to a million with pipelining. Memory-bound before CPU-bound
Wide-column store (Cassandra-class)	10,000 writes/s per node	Scales linearly with nodes
Search engine (Elasticsearch-class)	Thousands of documents/s indexing per node	Query rate depends heavily on query shape
Message broker (Kafka-class)	Hundreds of MB/s per broker; millions of messages/s per modest cluster	Partition count, not broker count, bounds a single consumer group
Load balancer	100,000+ concurrent connections	Rarely the bottleneck
Network interface	10 to 25 Gbps ≈ 1.25 to 3 GB/s	Divide bits by 8
NVMe SSD	3 to 7 GB/s sequential, 500,000 to 1,000,000 IOPS
Spinning disk	100 to 200 MB/s sequential, 100 to 200 IOPS	The IOPS number is why random reads on HDD are hopeless
Memory bandwidth	Tens of GB/s

Sizes of common things

Thing	Size	Memorize as
Integer, timestamp	4 to 8 bytes
UUID	16 bytes binary, 36 as text
Short text post (a tweet)	300 bytes
Typical database row with metadata	100 bytes to 1 KB	say 500 bytes
Log line	200 to 500 bytes
JSON API response	1 to 10 KB
HTML page (document only)	100 KB
Web page with all assets	2 MB
Compressed web image	200 KB to 2 MB
Phone photo	3 to 5 MB
One minute of 1080p streaming video (5 Mbps)	40 MB
One minute of 4K streaming video (20 Mbps)	150 MB
Base62, 6 characters	57 billion codes
Base62, 7 characters	3.5 trillion codes
64-bit integer range	18 quintillion (1.8 × 10^19)	Never runs out

Cloud cost ballparks (2026)

Resource	Ballpark	Note
Object storage (standard tier)	$0.02 per GB-month	Infrequent access about half that; archive tiers around $0.001 to $0.004
Block storage (SSD)	$0.08 per GB-month
Managed relational database storage	$0.10 to $0.25 per GB-month	Plus the instance
Managed in-memory cache	$10 to $20 per GB-month	Memory is 500 to 1,000 times object storage. This is why you size the working set carefully
Compute, general purpose	$0.04 to $0.05 per vCPU-hour on demand	A 2 vCPU, 8 GB box is roughly $60 to $70 per month. Reserved or spot is 30 to 70 percent less
Egress to the internet	$0.05 to $0.09 per GB	Ingress is free. Egress is the surprise on every first bill
Cross-region data transfer	$0.02 per GB
LLM API, mid-tier model	$3 input, $15 output per million tokens	Frontier models are 3 to 4 times that, budget models a third. See the pricing snapshot on the main blog

The ratios to remember: memory costs about a thousand times object storage per byte, and egress costs about the same per gigabyte as storing that gigabyte for two to four months.

Availability

Target	Downtime per year	Per month	Per day
99%	3.65 days	7.3 hours	14 minutes
99.9% (three nines)	8.8 hours	44 minutes	1.4 minutes
99.99% (four nines)	53 minutes	4.4 minutes	9 seconds
99.999% (five nines)	5.3 minutes	26 seconds	under a second

Two composition rules that interviewers love:

• Serial dependencies multiply. A service that depends on two 99.9% services in series is at best 99.8%. Ten of them: 99%. This is the argument against long synchronous call chains.
• Parallel redundancy squares the failure rate. Two independent 99.9% replicas where either can serve: 1 minus 0.001 squared, or 99.9999%. This is the argument for replicas, and the word “independent” is doing all the work.

Rules of thumb

Rule	Use it for
Little’s law: concurrency = throughput × latency	1,000 requests/s at 100 ms each means 100 requests in flight. Size thread pools, connection pools, and server counts with it
Run at 70 percent utilization	Queueing delay explodes past 80 percent. Plan headroom
Peak is 2 to 3 times average; 10 times for spiky	Say which you are using
Read to write ratio: 10:1 to 100:1 for typical consumer apps	Justifies caching and read replicas
80/20 for caching	20 percent of keys serve 80 percent of reads. Cache size = 20 percent of daily distinct reads
Replication factor 3	Multiply storage by 3 for anything you care about
Index overhead 20 to 50 percent	Add it to storage estimates
Text compresses 3 to 5 times; JSON 5 to 10 times	Estimate wire and storage size after compression
DAU × actions per day ÷ 100,000 = average QPS	The one-line conversion from product to engineering

How to Use Them in Ninety Seconds

The method is the same every time. Say each step out loud.

1. State the inputs as assumptions. “Assume 10 million daily active users, each uploading two photos a day, 4 MB each.”
2. Convert to a rate. “20 million uploads a day, about 200 per second average, plan for 600 at peak.”
3. Convert to a size. “80 TB of new photos a day, about 30 PB a year.”
4. Convert to a cost or a node count if it changes the design. “30 PB in object storage is about $600,000 a month at standard tier, so tiering to infrequent access and archive is a design requirement, not an optimization.”
5. Say so. “So the metadata is small and fits in one database. The blobs go to object storage with lifecycle rules. The design problem is the upload path at 600 per second and the CDN in front of reads.”

Three worked examples, each in the ninety-second form.

A chat system. 50 million DAU, 40 messages each per day. 2 billion messages a day, about 20,000 per second average, 60,000 at peak. At 100 bytes each that is 200 GB a day of message storage, 70 TB a year before replication, so about 200 TB provisioned. So: one relational primary cannot take 60,000 writes per second, and this is a wide-column store sharded by conversation, with the fan-out over WebSockets being the hard part.

A rate limiter’s counter store. 1 million active API keys, about 100 bytes of state each. 100 MB. So: this fits in one cache node with room to spare, and we shard for throughput and availability, not size.

Sizing an app tier with Little’s law. 5,000 requests per second at 200 ms average latency means 1,000 requests in flight. If a server comfortably holds 100 concurrent requests, that is 10 servers, or 15 with headroom, or 30 to 45 at a 2 to 3 times peak. So: this is a modest autoscaling group, and the interesting question is what the 200 ms is spent on.

Follow-Up Questions to Expect

• “Where did that number come from?” From the assumption you stated. Point back to it and offer to change it.
• “What if it is ten times bigger?” Re-run the one step that matters. Most designs survive 10x on storage and break on 10x write rate. Know which yours is.
• “Does that fit in memory?” Compare the working set to the cache size in the cost table. Say the ratio.
• “What does it cost?” Multiply by the ballpark and round. Then say which line item dominates. It is usually egress or memory, rarely storage.
• “How many nines do we need?” Ask what the business loses per hour of downtime, then pick the cheapest target that covers it. Every nine costs roughly ten times the previous one.
• “Is that peak or average?” Have already said. If you have not, say it now and multiply.

Key Takeaways

• A million a day is ten a second. A day is a hundred thousand seconds. Start every estimate here.
• The latency ladder in five rungs: memory 100 ns, SSD 100 µs, same-DC 0.5 ms, spinning disk 10 ms, cross-region 100 ms. Each rung is a thousand times the last.
• Per node: app server 1,000 to 10,000 requests per second, relational database about 10,000 mixed QPS, cache 100,000 ops per second.
• Memory costs a thousand times object storage. Egress is the surprise on every first bill.
• Three nines is 44 minutes a month. Four nines is 4 minutes. Serial dependencies multiply availability down; parallel replicas square the failure rate.
• Little’s law sizes everything: concurrency equals throughput times latency.
• Round hard, state assumptions, design for peak, add replication, and always end with “so.”

Further Reading

• Jeff Dean, Numbers Everyone Should Know (the original ladder, from a 2007 Stanford talk)
• Colin Scott, Interactive latency numbers by year
• Google SRE Book, Embracing Risk on availability targets and their cost
• Alex Xu, System Design Interview, chapter on back-of-the-envelope estimation