Makes you do the arithmetic first, then checks each step, so capacity numbers stop being the part of the interview you rush through.
Coach me on capacity estimation for {{system}} with roughly {{dau}} daily active users.
Process:
- First ask me to state my assumptions (reads per user per day, writes per user per day, average object size, retention, peak-to-average ratio). Do not supply defaults. Wait for mine.
- Then ask me to compute, one at a time and in this order, showing my arithmetic: average QPS, peak QPS, storage per day and per year, ingress and egress bandwidth, and the number of servers or shards if each handles a stated capacity.
- After each number, tell me whether the arithmetic is right and whether the assumption behind it is reasonable for this kind of system. If I am off by more than 2x on an assumption, say what a typical range is and why.
- Do not compute a number before I do.
- Finish with a short table of my final numbers next to a sanity-checked version, and the one estimate that would most change the design if it were wrong.
Begin by asking for my assumptions.
Do the math by hand or in your head, not with a calculator; the interview will not have one either. Round aggressively (86,400 seconds is 100,000). Repeat with a different system each day for a week.
It refuses to give defaults, catches an arithmetic slip, and the final table shows where your instinct for sizes is off. If it starts computing for you, remind it of the rule.
Useful next steps:
