-
State the core user assumptions:
- Total users:
100,000,000 - Daily active rate:
20%(0.20) - Feed opens per active user per day:
20
- Total users:
-
Convert reads per day to reads per second.
- Say aloud: “I’ll call a day one hundred thousand seconds” (a convenient mental rounding; actual day = 86,400s).
-
Account for traffic peaks with a peak factor (common practice: 3–5×).
- Announce: “I’ll round peak traffic to about 3–5×; let’s call it 15,000 reads/s for planning.”

Say your assumptions and rounding aloud. Those are the signals interviewers use to grade your reasoning.
How to use these numbers in design decisions
- Use the final reads/s to size front-end load balancers, web server pods, and API capacity.
- Multiply by average request cost (CPU, DB reads, cache hit rate) to size back-end services and databases.
- Convert reads/sec to IOPS, network bandwidth, and cache memory needs as you pick components (CDN, Redis, read replicas, etc.).