About ten minutes into a system design round, once the requirements are roughly settled, the interviewer says something like "assume 100M daily active users" and waits. They are asking you to turn that population into a few coarse numbers: request rates, requests in flight, stored bytes, the rate those bytes accumulate, and bytes leaving the system. Derive each number from premises you state yourself, then use it to rule a design option in or out. Capacity estimation bounds a choice. It does not forecast what the system will actually experience.

The estimate usually gets three to five minutes of a forty-five-minute round. A wrong order of magnitude propagates into every box you draw afterwards. At mid-level, a defensible requests-per-second figure and a rough storage figure are usually enough, provided each one changes a component choice. A senior answer may also need requests in flight, a separation between hot and stored data, and a judgment about which quantities are worth refining.

The useful practice is to state each premise, derive the quantity with units attached, and identify the design option that quantity eliminates. Arithmetic without a design consequence does not help you choose an architecture.