Interactive Capacity Estimator

Every capacity plan, and every system-design interview, starts by turning a product statement such as “ten million daily users” into numbers you can design against. This estimator runs that chain from users to requests per second, then to storage, bandwidth and node count, and shows each link so you can see which assumption moves the answer.

What it computes

avg QPS      = DAU × requests per user per day / 86,400
peak QPS     = avg QPS × peak factor
read QPS     = avg QPS × read %
write QPS    = avg QPS × (1 − read %)
storage/yr   = write QPS × payload × 31,536,000 s × replication
read bw      = read QPS × payload            bytes per second
nodes        = ⌈ storage/yr / usable storage per node ⌉

• DAU is daily active users, and requests per user is how many calls each makes in a day.
• Peak factor scales the average to the busiest period you must survive.
• Read % splits traffic into reads and writes. Only writes add storage.
• Payload is the size of one write in KB, counted as 1,024 bytes. The same size is used for reads.
• Replication is how many copies of each write are stored.

Byte totals use 1,024-based units (labeled KB, MB, TB), and counts above a thousand are abbreviated, with B meaning billions.

A worked example

The defaults describe a read-heavy service: 10 million DAU, 20 requests each, a 3× peak, 90% reads, 2 KB per write, 3 replicas and 2 TB usable per node.

Behind the storage line: 20 million writes a day at 2 KB is about 38 GB of new data daily and 13.6 TB a year before replication. Three replicas triple it. Note the bandwidth row uses the average read rate; at the 3× peak it is about 12.2 MB/s.

Assumptions and limits

• Read and write QPS are averages. They are derived from average traffic, not peak. Apply the peak factor yourself when sizing servers or links.
• One payload size for everything. Reads are assumed to return objects the size of a write. Feeds, search results and media responses are often far larger.
• One year, raw payload, no growth. Storage covers a single year of writes with flat traffic and ignores indexes, metadata, compression, deletes and the multi-year retention most systems need.
• Nodes are sized by disk alone. There is no headroom, no CPU or memory limit and no per-node request ceiling. It does not estimate cache size, servers per tier or network cost.
• Uniform users. Every user makes the same number of requests. Real usage is skewed, and heavy users drive hot keys.

How to use the result

Treat the output as the starting point for a design conversation:

• Peak QPS picks the architecture. A few thousand requests per second fits a modest fleet behind a load balancer. Hundreds of thousands calls for sharding, aggressive caching and careful hot-key handling.
• The read share decides where effort goes. At 90% reads, caching and read replicas pay off first; a write-heavy split points at partitioning and log-structured storage.
• Leave headroom on disks. Plan to run nodes well below full, for example at 70%, which turns 21 nodes into about 30, and multiply by the years of retention you need.
• Say the assumptions out loud. In an interview, stating the inputs and rounding boldly, such as 86,400 to 100,000, matters more than decimals. Change one slider to show which assumption the design is most sensitive to.

When to use it, and when not

Use it in the first ten minutes of a design: to learn whether you are building for hundreds of requests a second or hundreds of thousands, whether the data fits on one machine or needs sharding, and which input the answer is most sensitive to. It is also a fast check on someone else’s plan. If a proposal asks for 200 database nodes, you can see what traffic and payload that implies.

It is the wrong tool for buying hardware or setting a budget. Once a service exists, measured QPS, real object sizes and a load test answer these questions far better. It does not size CPU, memory, caches, queues or network cost. For a system whose load comes from background jobs, fan-out or streaming rather than user requests, DAU is the wrong starting input; start from events or jobs per second instead.

Trade-offs and limits

The node count is a floor. Each simplification the tool makes pushes the true figure up, and together they can multiply it. Starting from the default 21 nodes:

Units move it too. The tool counts a TB as 1,024⁴ bytes, but disk vendors sell decimal terabytes of 10¹² bytes. The default year is 44.85 trillion bytes. On nodes with 2 decimal TB usable that is 23 nodes, not 21. Check which unit your provider quotes before you divide.

Request load can also outgrow disk. Split evenly, 21 nodes at the 6.9K peak each take about 331 requests a second. If one node cannot serve that many, the request rate sets the count, not storage. The tool never checks.

Flat traffic is the last big simplification. If traffic doubles every year, the second year writes 81.6 TB on its own, and two years hold 122.4 TB, not 81.6. For a multi-year plan, run the tool once per year with that year’s expected DAU and add the storage results.

Common mistakes

• Sizing for the average. The read, write and bandwidth figures use average traffic. Peak writes in the default are 694 a second, not 231; provision links and write paths for that.
• Confusing bytes and bits. Network links are rated in bits per second. The default 4.1 MB/s of reads is 34.1 Mbit/s on average and 102.4 Mbit/s at the 3× peak.
• Treating DAU as concurrent users. Ten million daily users are not ten million open connections. Concurrency comes from request rate times request time, which is Little’s Law, not from DAU.
• One payload for reads and writes. A feed read may return 20 posts, and a search page many results. If reads return more bytes than a write stores, bandwidth scales with the read size, and the tool’s figure is too low.
• Losing a factor of the replicas. Replication multiplies storage but not the bytes users fetch. Applying it to bandwidth, or forgetting it for disks, is a 3× error either way.

Check yourself