Back-of-Envelope Estimation
Three minutes of rough arithmetic that decides whether you need one machine or a hundred. Precision is never the goal. Finding the number that changes the design is.
Prerequisites: Powers of two and a willingness to round hard.
Cover these firstScaling Fundamentals
After this: Size a system out loud in two minutes and let the numbers pick the architecture.
Suggested first pass: Read sections 1–5, answer each section in your own words, then use the remaining failure modes and exercises as the advanced pass.
Estimation feels like ritual: multiply users by posts, write it on the board, move on. It becomes useful the moment you attach a question to it. Does this number change what I build?
Only a few outcomes matter:
- Does the data fit on one machine?
- Does the working set fit in memory?
- Is the write rate something an ordinary database handles?
Each answer opens or closes an entire branch of the design. If all three are "comfortably yes", you have saved twenty minutes of architecture nobody needed.
Use 100,000 seconds for a day (it is 86,400). Call a million 106 and a billion 109. Turn 3.7 into 4. Nobody is checking your arithmetic. They are checking whether you can tell a big number from a small one and act on the difference.