System Design · core
Capacity Estimation
Back-of-the-envelope QPS, storage, and bandwidth maths that sizes a design before you draw it.
Mental model
Estimation exists to eliminate designs, not to be accurate. One order of magnitude is the whole game: 100 GB/day means one machine, 100 TB/day means a fleet, and that single answer picks your storage engine, your sharding story, and whether replication is affordable. Do it before the boxes-and-arrows, because a design drawn without a number is a design you cannot defend.
How to study Capacity Estimation
Begin by restating the mental model in your own words, then connect it to a concrete system you have built or operated. Name the mechanism, the constraint it addresses, and the trade-off it introduces. Use Site Reliability Engineering (Google) — chapter 21: Handling Overload to check details, but close the source before writing your explanation. Retrieval is the learning step; rereading is only preparation.
Next, compare Capacity Estimation with Load Balancing, Requirements Scoping. Ask what changes in correctness, latency, resource use, operability, and failure recovery. Complete Size a write-heavy service and preserve the command, input, output, and one failed attempt as evidence. Finish by explaining the idea without jargon to someone who has not studied the track.
Proof of understanding
- Explain the mechanism from first principles and identify the state it reads or changes.
- Give one situation where the concept is the right choice and one where it is not.
- Predict a realistic failure mode before running the drill, then compare the prediction with evidence.
- Connect the result to a roadmap or build artifact instead of treating the concept as isolated trivia.
Where it matters
The first five minutes of every HLD interview, and the calculation that decides whether a feature needs a queue or a cron job.
Common mistakes
- Chasing precision — carrying three significant figures through an estimate whose input was a guess
- Estimating average load and sizing for it, when peak is what falls over; assume peak is several times the mean
- Forgetting the multipliers that dominate: replication factor, indexes, and retention window often exceed the raw payload
- Quoting a storage number without a time horizon — per day and per year lead to different architectures
Learn from primary sources
Practice and explain it back
Size a write-heavy service
Implement size(dau, writesPerUserPerDay, bytesPerWrite, replicationFactor, peakMultiplier) returning { writesPerSecond, peakWritesPerSecond, storagePerDayGB, storagePerYearTB }. Use 86400 s/day and 365 d/yr. Storage counts replication. Use GB = 1e9 bytes and TB = 1e12 bytes (decimal, as capacity planning does). Round every value to the nearest integer.
Expected evidence: size(10e6, 20, 500, 3, 5) -> { writesPerSecond: 2315, peakWritesPerSecond: 11574, storagePerDayGB: 300, storagePerYearTB: 110 }
Open the interactive drill →Review prompts
- Why is a back-of-the-envelope estimate useful even when the inputs are guesses, and what makes an estimate that is wrong by 10x different from one wrong by 2x?
Build evidence
Use a roadmap capstone to turn this concept into working evidence.
Prerequisites
None assigned yet.