How do you estimate capacity for a system design?

Capacity estimation is not about a perfect number. It is about showing that the architecture is sized in the right order of magnitude and identifying which resource will run out first. Write the assumptions down so the interviewer can correct one and see the design adapt.

A repeatable method

• Start with daily active users and actions per user per day
• Convert to average QPS, then multiply by a peak factor, often three to ten
• Estimate read and write ratios separately because they stress different paths
• Multiply payload size by QPS for bandwidth, and by retention for storage
• Divide by a safe per-node capacity to get instance counts, then add headroom
• Sanity-check with cost, connection limits and a known bottleneck such as disk IOPS

For example, 10 million daily users each making 20 reads and 2 writes gives 200 million reads and 20 million writes per day. That is roughly 2,300 reads per second and 230 writes per second on average. At a peak factor of five, plan for about 11,500 reads per second and 1,150 writes per second. If a node handles 2,000 reads per second comfortably, you need at least six read-serving instances before redundancy and headroom.

Storage follows the same pattern. At 1 kilobyte per write and 20 million writes per day, new data is about 20 gigabytes per day, or roughly 7 terabytes per year before replication and indexes. Multiply by the replication factor and add index overhead. Then ask whether that volume fits the chosen store and backup window.