Kapazitätsabschätzung
Überschlagsrechnung: Anfragen pro Sekunde, Speicher und Bandbreite, Lese/Schreib-Verhältnisse und die Latenzzahlen, die jeder Entwickler im Kopf haben sollte.
Deutsche Übersetzung in Arbeit
Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.
Auf dieser Seite
Step 2 of the approach is estimation, and it's the step that intimidates people most and matters most. You don't need exact numbers - you need a back-of-the-envelope sense of scale: is this thousands of requests per second or millions? Gigabytes or petabytes? These rough figures decide whether one server suffices or you need sharding, caching, and queues. Estimation is a learnable skill built on a handful of numbers and simple arithmetic.
Why estimate at all
Estimation converts "design a system for lots of users" into concrete pressure you can design against:
- Requests per second (QPS) tells you how many servers and how much parallelism you need.
- Storage tells you whether data fits on one machine or must be sharded.
- Bandwidth tells you about network and CDN needs.
- Read/write ratio tells you where to focus - a 100:1 read-heavy system screams caching and read replicas.
Get these to the right order of magnitude and the architecture almost designs itself. Precision isn't the goal; the goal is knowing whether you're at 10, 10 thousand, or 10 million.
The method: round, then multiply
Use round numbers and powers of ten. A worked example - a link shortener with 100 million new links/day and a 100:1 read:write ratio:
Writes/sec: 100,000,000 / 86,400 s ≈ 100M / 100K ≈ ~1,000 writes/sec
(86,400 s/day rounds to ~100,000 for easy math)
Reads/sec: 1,000 × 100 = ~100,000 reads/sec ← read-heavy → cache + replicas
Storage: each link ≈ 500 bytes
100M/day × 500 B = 50 GB/day
× 365 × 5 years ≈ ~90 TB ← too big for one node → shard
Read bandwidth: 100,000 reads/sec × 500 B ≈ 50 MB/sec outThe math is deliberately crude (86,400 ≈ 100,000), and that's fine - you're finding the order of magnitude. The conclusions are what matter: ~100K reads/sec and ~90 TB immediately tell you this needs caching, read replicas, and sharding - none of which you'd know without the estimate.
Numbers worth memorizing
A few reference points make estimation fast. First, the units and time:
- 1 day ≈ 86,400 seconds (≈ 10^5 for quick math).
- Powers of ten: thousand (10^3, KB), million (10^6, MB), billion (10^9, GB), trillion (10^12, TB).
Second, the classic "latency numbers every programmer should know" (orders of magnitude, from Jeff Dean) - because a design's performance is dominated by which of these it hits:
L1 cache reference ~1 ns
Main memory (RAM) reference ~100 ns
Read 1 MB sequentially from RAM ~10 μs
SSD random read ~100 μs (0.1 ms)
Read 1 MB from SSD ~1 ms
Round trip within a datacenter ~0.5 ms
Disk (HDD) seek ~10 ms
Read 1 MB from disk (HDD) ~20 ms
Network round trip US ↔ Europe ~150 msThe takeaways that drive design: memory is ~1000× faster than SSD, which is faster than disk; a cross-continent round trip (~150 ms) dwarfs everything local. This is why caching in RAM helps so much, why a CDN near users matters, and why chatty cross-datacenter calls kill latency.
Round aggressively and state your assumptions
The goal is an order of magnitude, so round mercilessly - 86,400 → 100,000, 512 bytes → 500, 0.9 → 1. What matters far more than arithmetic precision is stating your assumptions out loud ('assume 100M writes/day, 100:1 reads, 500 bytes/record') so your estimate is reproducible and your reasoning is visible. An interviewer (or a design reviewer) is judging whether you can reason to the right scale, not whether you can divide by 86,400 in your head.
Before building a restaurant, you estimate: how many diners per night, average meal time, peak vs. off-peak. You don't need the exact number - you need to know if it's a 20-seat bistro or a 500-cover banquet hall, because that decides everything: one chef or a brigade, a domestic fridge or a walk-in cold room, one till or ten. Guessing 'roughly 300 covers on a Friday, most between 7 and 9pm' immediately tells you the kitchen and staffing you need. Capacity estimation is sizing the kitchen before you build it: rough numbers about load and storage tell you whether one server and one database will do, or whether you need the full brigade of caches, replicas, and shards. Build the kitchen for the wrong size and you either can't serve the rush or waste a fortune on an empty hall.
Estimate the scale for a Twitter-like service: 200 million daily active users, each posting on average 2 tweets/ day and reading their timeline 50 times/day, where each timeline read returns ~20 tweets. Compute rough writes/ sec and reads/sec (tweet fetches/sec), state the read:write character, and say what one architectural implication follows.
Why do back-of-the-envelope capacity estimates matter in system design?
Key takeaways
- Estimation turns 'design for lots of users' into concrete pressure: QPS (compute), storage (sharding), bandwidth (CDN), and read/write ratio (where to optimize).
- Use round numbers and powers of ten - the goal is the right order of magnitude, not precision; state your assumptions out loud.
- Memorize a few anchors: ~86,400 s/day (~10^5), and the latency hierarchy (RAM ~100 ns, SSD ~0.1 ms, datacenter round trip ~0.5 ms, cross-continent ~150 ms).
- The latency numbers explain design: RAM is ~1000x faster than SSD, and a cross-continent round trip dwarfs local work - hence caching and CDNs.
- The estimate's conclusions (read-heavy, too big for one node) point directly at the architecture: caching, read replicas, and sharding.