Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path
Interactive Capacity Estimator
Slide DAU, requests per user, payload size and read/write ratio and watch QPS, storage per year, bandwidth, shard count and cache memory recompute live — every number with the formula behind it. The napkin math interviewers expect, made interactive.
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.
| Output | Working | Shown |
|---|---|---|
| Average QPS | 200,000,000 / 86,400 = 2,314.8 | 2.3K |
| Peak QPS | 2,314.8 × 3 = 6,944.4 | 6.9K |
| Read QPS | 2,314.8 × 0.9 = 2,083.3 | 2.1K |
| Write QPS | 2,314.8 × 0.1 = 231.5 | 231 |
| Storage / year | 231.5 × 2,048 B × 31,536,000 × 3 = 44.85 trillion bytes | 40.8 TB |
| Read bandwidth | 2,083.3 × 2,048 B = 4.27 million bytes/s | 4.1 MB/s |
| Storage nodes | ⌈40.8 / 2⌉ | 21 |
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.
How it works
- Average QPS = DAU × requests/user ÷ 86,400 seconds in a day.
- Peak QPS = average QPS × your peak-to-average factor.
- Storage/year = write QPS × bytes/write × 31.536M seconds × replication.
- Storage nodes = ⌈storage/year ÷ usable TB per node⌉.
Frequently asked questions
What is back-of-the-envelope estimation in system design?
It is the quick capacity math done early in a design discussion or interview: turning daily active users and per-user activity into queries per second, then into storage, bandwidth and the number of machines you will need. The goal is the right order of magnitude and a clear list of assumptions, not a precise number. An estimate that is off by 20% is fine; one that is off by 100 times leads to the wrong architecture.
How do you calculate QPS from daily active users?
Average QPS equals daily active users times requests per user per day, divided by the 86,400 seconds in a day. Ten million users making 20 requests each is 200 million requests a day, or about 2,315 per second. Because traffic is bursty, multiply by a peak-to-average factor to get peak QPS, which is what you provision for. With a factor of 3 that example peaks at about 6,900 requests per second.
Why multiply by a peak factor?
Traffic is never spread evenly across the day: there are busy hours, quiet hours, weekly cycles and launch-day spikes. If you size only for the average you fall over at the peak. A peak-to-average factor of 2 to 3 is a common starting assumption for steady consumer traffic. Raise it for spiky workloads such as ticket sales, flash promotions or anything driven by notifications sent to many users at once.
How is yearly storage estimated?
Storage per year equals writes per second times bytes per write times the seconds in a year, about 31.5 million, times the replication factor, because each write is stored on several replicas for durability. At 231 writes per second of 2 KB with three replicas, that is about 40.8 TB a year. It is a first-year figure for the raw payload, so add indexes, metadata and growth before buying disks.
How many storage nodes do I need?
Divide the yearly storage, including replication, by the usable capacity of one node and round up. Forty point eight terabytes on nodes with 2 TB usable each needs 21 nodes. This counts space only. Real clusters also need headroom so disks never run full, room for growth beyond the first year, and enough nodes to handle the request rate, so the true number is usually higher than the storage-only figure.
How do you estimate bandwidth for a system design?
Multiply the request rate by the size of each response. This calculator takes the read QPS and the payload size, so 2,083 reads per second of 2 KB is about 4.1 MB per second of outbound traffic on average. Two cautions apply: it uses average rather than peak read QPS, so multiply by the peak factor for provisioning, and it assumes reads return objects the same size as writes, which is often not true.