Quick capacity maths for interviews
Open in the interactive app: practice, quiz, mock interview →In one minute
- Back-of-envelope estimation exists to make decisions: does this fit on one machine, does it need sharding, is a cache worth it, what dominates cost. An estimate that does not change a decision is wasted interview time.
- Memorise a small set of anchors: 86,400 seconds a day (call it 100k), 1 million per day is about 12 per second, 1 Gbit/s is 125 MB/s, a memory reference is about 100 ns, an SSD random read about 100 microseconds, a same-datacenter round trip about 0.5 ms, a cross-continent round trip about 100 ms.
- The template: users times actions gives QPS; QPS times bytes gives bandwidth; writes times bytes times retention times replication gives storage; peak is average times a factor of 2 to 10.
- Round aggressively, say your assumptions out loud, and keep two significant figures at most. Interviewers grade the method and the conclusion, not the third digit.
- Staff-level signal: you estimate the bottleneck resource, not every resource, and you sanity-check the result against what one machine can do.
How it works
The numbers worth memorising
Latency, roughly, on modern hardware (treat these as orders of magnitude; exact figures vary by generation). The classic table most people memorise dates from about 2012 and still lists a 4 KB SSD random read at 150 microseconds and a California to Netherlands round trip at 150 ms (system-design-primer). The popular "by year" version is extrapolated from growth curves rather than measured: it pins SSD random reads at 16 microseconds from 2014 onward and projects memory and SSD bandwidth forward, so its recent sequential-read figures are far faster than real hardware (Colin Scott). Use the ranges below.
- L1 cache hit: about 1 ns. Main memory reference: about 100 ns.
- Compress 1 KB with a fast codec: a few microseconds.
- Read 1 MB sequentially from memory: tens to a few hundred microseconds depending on the hardware.
- NVMe SSD random 4 KB read: about 20 to 100 microseconds. Read 1 MB sequentially from SSD: about 0.2 to 1 ms.
- HDD seek: about 5 to 10 ms.
- Round trip within a datacenter: about 0.2 to 0.5 ms. Between AZs: about 1 ms; AWS keeps the AZs of a region within 100 km of each other, which puts the fibre floor under 1 ms (AWS). Coast to coast in the US: about 60 to 80 ms. Transatlantic or transpacific: about 80 to 150 ms.
Throughput and capacity anchors (hedged; real limits depend heavily on payload and tuning):
- A 10 Gbit NIC moves about 1.25 GB/s; 25 Gbit about 3 GB/s.
- One NVMe SSD: hundreds of thousands of random read IOPS, and roughly 1 to 7 GB/s sequential.
- A stateless web or API server: from about 1,000 to tens of thousands of simple requests per second.
- A single Postgres or MySQL primary: thousands to low tens of thousands of simple writes per second; more reads, especially from cache.
- One Redis instance: around 100,000 or more simple operations per second; Redis's own benchmark page shows about 180,000
SETs per second without pipelining and over 1.5 million with a pipeline of 16, and warns that the network often runs out before the CPU, since 4 KB values at 100,000 per second already need 3.2 Gbit/s (Redis docs). - One Kafka partition: tens of MB/s of writes, depending on batching, compression, acks and replication; size partitions as the larger of target throughput divided by per-partition produce rate and by per-partition consume rate (Confluent).
Sizes: an ID or timestamp is 8 bytes; a UUID 16 bytes; an English character in UTF-8 1 byte; a short text post with metadata 0.5 to 1 KB; a compressed photo 200 KB to 2 MB; a minute of 1080p video at streaming bitrates roughly 30 to 60 MB.
Time conversions: a day is 86,400 s, a month about 2.6 million s, a year about 31.5 million s. So 1 million events a day is about 12 per second, 1 billion a day about 12,000 per second.
The estimation template
- Users and actions. DAU times actions per user per day gives events per day.
- QPS. Events per day divided by 100,000 (or 86,400). Multiply by a read-to-write ratio for reads.
- Peak. Multiply by a peak factor: 2 to 3 for smooth global traffic, 5 to 10 or more for spiky events.
- Storage. Writes per day times bytes per write times retention days times replication (often 3), plus index and overhead (add 20 to 50 percent).
- Bandwidth. QPS times payload size, separately for ingress and egress.
- Machines. Peak load divided by per-machine capacity at a target utilisation (often 50 to 70 percent).
- Conclusion. One sentence that changes the design: "120 GB a day means about 650 TB over five years with replication, so we need a sharded or object store, not one database node."
What interviewers look for
They want to see you choose round numbers, state assumptions, carry units, and land on a decision. They also notice when candidates over-invest: spending eight minutes estimating everything to three digits leaves no time for the design. Two to four minutes is usually right.
Common mistakes
- Forgetting replication and indexes in storage, which can triple or quadruple the number.
- Mixing bits and bytes in bandwidth (a factor of 8).
- Estimating average QPS and sizing for it, ignoring peaks.
- Computing many numbers but never stating what they imply.
- Using precise arithmetic where powers of ten would do; it is slow and error-prone at a whiteboard.
- Treating QPS as the capacity unit when request costs differ. A search and a profile read are not the same "query". Google's SRE book calls QPS a moving target and provisions in CPU instead (SRE book, ch. 21); in an interview, at least split cheap and expensive requests.
Down the stack
Layer 1The contract
An estimate promises order-of-magnitude correctness under stated assumptions, not precision. A good one is falsifiable: "about 5,000 writes per second at peak, assuming 50 million DAU and 3 posts per user per day with a peak factor of 3". When an assumption changes, the interviewer can follow the arithmetic and see the new answer. The useful output is a bound that decides architecture: within one node's capacity or not, within one NIC or not, within RAM or not.
Layer 2The mechanism
A few laws turn rates into resources. Little's Law says the average number of requests in flight equals arrival rate times time in system: at 20,000 requests per second and 50 ms per request, about 1,000 are in flight, which sizes thread pools, connection pools and memory for buffers. Utilisation drives queueing delay: in a simple M/M/1 model, time spent waiting in the queue is the service time multiplied by rho / (1 - rho) (M/M/1 queue), so going from 50 percent to 90 percent utilisation multiplies queueing delay by about nine, which is why targets sit around 50 to 70 percent. Storage grows with write amplification: B-tree indexes add a page write per index, LSM compaction rewrites data several times, and replication multiplies everything. Fan-out multiplies load: a feed read that queries 200 followees is 200 backend reads per request. It also multiplies tail latency: if each backend is slow 1 percent of the time, a request that waits for 100 of them is slow 1 - 0.99^100, about 63 percent of the time, so a fan-out estimate should use the backends' p99, not their average.
Layer 3The machine
The latency anchors come from physics and hardware. Light in fibre covers about 200 km per millisecond, so a 6,000 km route has a 60 ms round-trip floor before any routing detours; New York to London is 56 ms on an ideal great-circle path, and real routes are longer (High Performance Browser Networking, ch. 1). A DRAM access around 100 ns reflects row activation and memory controller queues; a cache line is 64 bytes, so streaming memory is far faster than random access. SSD random reads cost tens of microseconds because each read goes through the controller's flash translation layer and a NAND page read. A 4 KB page at 100,000 IOPS is about 400 MB/s, so small random reads saturate IOPS before bandwidth, while large sequential reads saturate bandwidth first. Networks carry about 1,460 bytes of payload per standard Ethernet frame, so a 1 MB response is about 700 packets; at 10 Gbit/s that is roughly 0.8 ms on the wire.
Why it's built this way
Interviews are short and designs depend on scale, so you need a fast way to know which regime you are in. Google's SREs use the same arithmetic in real design reviews: in the workbook's AdWords example, 500,000 queries per second with 2 KB log entries is about 86 TB of logs a day, and at about 200 IOPS per hard disk the naive single-machine design would need about 2,500 disks, which is what forces a distributed design (SRE Workbook, ch. 12). Hardware capabilities change slowly in order of magnitude even as exact numbers shift, so a few anchors stay useful for years. Queues explode near saturation, so capacity plans leave headroom. And because the bottleneck decides the architecture, the skill is finding the one resource that runs out first.
Diagram
flowchart LR
U["DAU x actions/day"] --> E["Events/day"]
E -->|"/ 86,400"| Q["Avg write QPS"]
Q -->|"x read ratio"| R["Avg read QPS"]
Q -->|"x peak factor"| P["Peak QPS"]
E -->|"x bytes x days x replicas"| S["Storage"]
Q -->|"x bytes"| B["Bandwidth"]
P -->|"/ per-server capacity"| M["Servers"]Worked example
A photo-sharing service: 100 million DAU, each uploads 0.2 photos a day and views 50 photos a day. Average photo after compression is 500 KB, plus 2 KB of metadata. Keep photos forever (plan for 5 years); 3 copies of metadata, and object storage with its own durability.
Uploads: 100 million times 0.2 is 20 million per day, about 230 per second, peak about 700 per second at a factor of 3. Ingress: 230 times 500 KB is about 115 MB/s average, roughly 1 Gbit/s, and about 3 Gbit/s at peak. Fine for a fleet, and a reason to upload directly to object storage with pre-signed URLs.
Views: 100 million times 50 is 5 billion per day, about 58,000 per second, peak about 175,000 per second. Egress: 58,000 times 500 KB is about 29 GB/s, roughly 230 Gbit/s average. That number is the headline: it must come from a CDN, not origin servers.
Storage: 20 million times 500 KB is 10 TB a day, about 3.65 PB a year, about 18 PB over 5 years before thumbnails. Metadata: 20 million times 2 KB times 3 replicas is 120 GB a day, about 220 TB over 5 years, which needs a sharded metadata store.
Decision: CDN-first serving, object storage with lifecycle tiering for older photos, sharded metadata, and a cache for hot metadata. One estimate changed three design choices.
In the wild
- Pokémon GO, 2016: the worst case was off by 10x. Niantic planned for 1x launch traffic with 5x as the worst case, and player traffic reached 50x, measured through Cloud Datastore load. Google added tens of thousands of cores, and before the Japan launch Niantic upgraded GKE to allow more than 1,000 additional nodes and moved to the HTTP/S load balancer, so that launch passed without a major incident (Google Cloud).
- AWS Kinesis, 2020: a per-server resource that grew with the fleet. Each front-end server created an operating system thread for every other server in the front-end fleet, so adding capacity pushed every server past the operating system's thread limit at once. Shard-map caches could not be built, Kinesis was impaired for about 17 hours, and Cognito, CloudWatch, Lambda and others were affected. Fixes included fewer, larger servers and alarms on thread use (AWS).
- AWS Lambda, 2023: a cell grew past its tested size. In us-east-1 a Lambda Frontend cell scaled up for normal growth, crossed a capacity threshold it had never reached, and hit a latent bug that allocated execution environments without using them. Synchronous invocations took about two hours to recover, and AWS planned to bound every cell to well-tested sizes (AWS).
Trade-offs
| Option | Strengths | Weaknesses | Choose when |
|---|---|---|---|
| Powers of ten rounding | Fast, low error risk | Off by up to about 2x | Whiteboard interviews |
| Precise arithmetic | Exact | Slow, distracts from design | Capacity planning docs |
| Average-based sizing | Simple | Underprovisions for peaks | Batch systems with queues |
| Peak-based sizing | Survives spikes | Idle capacity off-peak | User-facing, latency-sensitive paths |
| Bottleneck-only estimate | Saves time, drives decisions | May miss a second bottleneck | Most interviews |
Pitfalls in production
- Peak factor guessed, not measured. Launches and live events can exceed 10x average. Use measured historical peaks and load test beyond them.
- Forgotten overheads. Indexes, replicas, backups, snapshots and compaction space can double or triple raw storage. Add explicit multipliers.
- Ignoring growth. A system sized for today runs out in nine months. Model growth and set alerts at 60 to 70 percent of capacity.
- Per-server capacity from a benchmark. Benchmarks with tiny payloads overstate real capacity. Measure with production-shaped requests.
- Egress cost surprises. Cross-region and internet egress is billed per GB; at 230 Gbit/s it dominates the bill. Estimate cost, not only capacity.
Leadership lens
- Ask for the estimate behind every capacity claim in a design doc, with assumptions listed, and revisit it after launch with real numbers.
- Turn the bottleneck estimate into a dashboard and an alert; that is the cheapest early warning you will get.
- Include cost per unit (per request, per GB stored, per GB served) in estimates; it is often the deciding factor between designs.
Check yourself
A service gets 500 million requests per day. What is the average QPS, and what peak would you plan for?
Show answer
About 5,800 per second on average; plan for roughly 15,000 to 30,000 at a peak factor of 3 to 5 depending on how spiky the traffic is.
Why do you multiply storage by replication and add overhead?
Show answer
Each replica stores a full copy, and indexes, metadata and free space add tens of percent, so raw data understates disk by 3 to 4 times.
At 20,000 requests per second with 50 ms latency, how many requests are in flight?
Show answer
By Little's Law, 20,000 times 0.05 is 1,000 concurrent requests.
Why size servers for 60 percent utilisation instead of 100 percent?
Show answer
Queueing delay grows sharply as utilisation approaches 100 percent, and you need headroom for failures and spikes.
Sources and further study
Primary
- Jeff Dean, "Designs, Lessons and Advice from Building Large Distributed Systems" (LADIS 2009 keynote): the original "Numbers Everyone Should Know" slide (it has no SSD row; that was added later) and a worked estimate for a page of 30 image thumbnails.
Systems docs
- Redis benchmarks: real single-instance throughput, the effect of pipelining, and why the NIC is often the limit.
- AWS Regions and Availability Zones: the distance bound behind the cross-AZ latency anchor.
- Confluent: how to choose the number of partitions: per-partition throughput and the partition-count formula.
Books
- System Design Interview, Volume 1, Alex Xu, chapter 2 "Back-of-the-envelope Estimation": the interview template with powers of two and availability numbers.
- The Site Reliability Workbook, Beyer et al., chapter 12 "Introducing Non-Abstract Large System Design": full worked estimates for disks, RAM, network and machines.
- Systems Performance (2nd ed.), Brendan Gregg, chapter 2 "Methodologies": utilisation, saturation and queueing models behind headroom targets.
Other curricula
- donnemartin/system-design-primer: frames estimation as a lookup table of latency and powers of two, plus handy throughput rules such as about 30 MB/s from a hard disk.
Watch
- Back-Of-The-Envelope Estimation / Capacity Planning (ByteByteGo): a compact walkthrough of the interview estimation template.
- Latency Numbers Programmer Should Know (ByteByteGo): the latency anchors with modern context.
- Building Software Systems At Google and Lessons Learned (Stanford): Jeff Dean's talk that popularised back-of-envelope design with these numbers.
Free resources
- Latency numbers every programmer should know (gist): the classic table, worth knowing even though some figures are dated.
- Interactive latency numbers by year (Colin Scott): how the numbers have shifted with hardware generations.
- Building Software Systems at Google (Jeff Dean, slides): the original slides with worked estimation examples.
- Little's law (Wikipedia): the relation between rate, latency and concurrency.
- Handling overload (Google SRE book): why utilisation targets and headroom matter in practice.