Before you design anything, how do you run the capacity estimation for a new system — say a link-shortener doing a few hundred million reads a day — and how do those numbers actually change your design?

system-design · Staff-principal level · software-engineering

What the interviewer is really asking

Assesses whether the candidate treats back-of-envelope estimation as a design driver — converting traffic into QPS, storage, and bandwidth and letting those numbers pick the architecture — rather than reciting formulas for show.

What to say

• Convert the top-line number into the metrics that drive decisions: average QPS = daily requests / 86,400, then apply a peak factor (commonly 2-5x, or the Pareto 'most traffic in a fraction of the day' heuristic) to get peak QPS, then read:write ratio. State your assumptions out loud so the interviewer can correct them.
• Derive storage and bandwidth from there: items/day times years of retention times bytes/item for storage; QPS times payload size for egress bandwidth. A 100:1 read:write ratio immediately tells you reads should be cache- or replica-served and writes can sit on a single primary.
• Tie each number to a lever: if peak read QPS dwarfs what one DB handles, you've justified a cache and read replicas; if writes are tiny, a single-writer KV store is enough; if storage is petabytes, object storage plus an index beats a fat relational table. Round aggressively — the goal is the right order of magnitude, not precision.

What to avoid

• Produce numbers with false precision (1,847,293 QPS) — interviewers want the order of magnitude and the reasoning, not arithmetic theatre.
• Compute the estimates and then design something unrelated to them, so the math was decoration that never touched a single architectural choice.
• Skip the read:write ratio and peak factor and plan capacity purely on the daily average, which under-provisions for the spike that actually breaks the system.

Example answers

Strong: For a few hundred million reads/day I'd round to ~300M reads, so ~3,500 average read QPS, and apply a 4x peak factor for ~14,000 peak read QPS. Writes are maybe 1% of that — ~35 write QPS. That 100:1 ratio is the whole story: writes go to a single primary, reads are served from a cache plus read replicas, and I size the cache to hold the hot working set rather than the full corpus.

Weak: I'd estimate around 1.8 million QPS and use a microservices architecture with Kafka and Cassandra to handle the scale. (Number is implausibly high for the stated load and the architecture is chosen before the math justifies anything.)