An estimate that changes nothing was wasted
An estimate that does not change the design is decoration.
The workflow that earns its keep: work out demand, compare it to what one machine does, and let the ratio pick the architecture. Under a tenth of a ceiling, use one machine and move on. Within a few multiples of it, add the standard mitigation, so a cache, a copy, a content delivery network, or compression. Past a ceiling with those already applied, and only then, reach for partitioning.
Bandwidth deserves its own comparison, because it is the estimate people skip. A thousand requests a second returning 100 KB each is 100 MB a second, which is 800 megabits, and that saturates a one gigabit network card with nothing spare.
One number can flip the answer
Change one number and the conclusion flips. A thousand requests at 2 KB is 2 MB a second, 16 megabits, nothing at all. The heavy-response case forces a content delivery network or compression long before it forces more servers.
Storage totals pick your storage system. Under a few terabytes fits on one of your database nodes with room to grow. Tens of terabytes still works on one machine, though backup and migration windows get frightening, so you start splitting hot data from cold. Hundreds of terabytes and beyond means object storage, partitioned databases, or both, plus policies that push stale data down a tier.
Which resource binds first matters, because it is rarely the one people assume. A media product usually hits bandwidth before storage. An analytics pipeline hits write rate before either. A business product often never leaves the first band on any axis, and the correct architecture there is a boring single application on a managed database.
Narrate the comparison, not just the demand you calculated. Saying “115 requests a second against a web tier that does 10,000 per instance, so two instances for redundancy, not twenty for load” shows you know what the numbers are for.
Worked example
Priya gets 'design a podcast host' in an interview: 5 million listeners, one 30-minute episode each per day. Audio at about 1 MB per minute makes each listen 30 MB, times 5 million is 150 TB of egress a day. Over 86,400 seconds that's about 1.7 GB per second average, call it 14 Gbps, maybe 40 Gbps at peak. No origin fleet serves that sensibly, so the decision makes itself: audio goes behind a CDN, and the origin only sees misses on new episodes. The metadata side is the opposite story: 5 million plays a day is about 60 API requests per second, a rounding error for one Postgres node. Her final design is deliberately lopsided, a large CDN contract next to a tiny database, and the interviewer's feedback says 'let the numbers drive it.'