Design Method & StylesChapter 15 · Open the room
Back-of-the-envelope estimates
Back-of-the-envelope estimates
A back-of-the-envelope estimate turns the requirements into the few numbers that shape a design — requests a second on average and at peak, how many reads per write, storage per year and bandwidth — in a couple of minutes, with round numbers and powers of ten. It only has to be right within a factor of ten. What it's for is the number that changes the design — when photos come to petabytes and their rows to terabytes, they don't belong in the same store.
- Use when
- After the requirements, before drawing boxes — to learn which parts are big · Checking whether one machine or one database can hold or serve something · Spotting the component whose number is out of line with all the others
- Avoid when
- Instead of capacity planning and load tests (core/capacity-math) · When the interviewer hands you the numbers — use them and move on · For numbers that don't change any decision
- Trade-offs
- Hard rounding (100,000 seconds a day, a stated peak factor) is fast and within a factor of ten — enough to choose a design, not to buy hardware · Every minute of arithmetic is a minute not spent on the design · Assumptions keep you moving but must be said out loud, so they can be corrected
- Requires
- Requirements and scope
3 objectives · 5 misconceptions
- predict Turn daily users and actions per user into average and peak requests a second, a read:write ratio, storage per year and bandwidth, using round numbers and about 100,000 seconds in a day.
- recall Recall the orders of magnitude on the latency ladder — memory, SSD, a round trip inside a data center, a round trip across an ocean — and use them to check whether a latency target is reachable at all.
- choose Choose which estimate changes the design, sanity-check each result against what one machine or one store can handle, and leave fleet sizing to capacity math.
- Not true: The estimate has to be exact, so take your time over the arithmetic.
- Not true: Daily requests divided by the seconds in a day is the load to design for.
- Not true: Estimate every number you can think of before designing anything.
- Not true: Storage is one number — the rows times the row size.
- Not true: Estimation is a ritual; the design comes out the same without it.
Practice
No katas practise this yet.