Back-of-the-envelope capacity calculator
Every system design interview opens the same way: how many users, how many requests, how much storage. This does that arithmetic live and shows its working, so you can check your instinct against it until you no longer need it.
Runs in your browser. Nothing is sent anywhere.
347
Average QPS
1.04K
Peak QPS
3x average
34.7
Writes per second
20.3 MB/s
Peak egress
New data per day
5.72 GB
Before replication. This is the number that decides whether one database is enough.
Total at 5y, 3 copies
30.6 TB
Replication is the multiplier people forget. Three copies of a petabyte is three petabytes you pay for.
Show the arithmetic›
requests/day = 1M users x 30 = 30M
avg qps = 30M / 86,400 s = 347
peak qps = 347 x 3 = 1.04K
writes/s = 347 x 10% = 34.7
storage/day = 3M writes x 2 KB = 5.72 GB
total = 5.72 GB x 365 x 5 x 3 = 30.6 TB
peak egress = 1.04K qps x 20 KB = 20.3 MB/s
The part worth repeating
1M daily users is 1.04K requests a second at peak.
Capacity gets sized against the average and then meets the peak, which is where the estimate goes wrong. The storage is the other half: 5.72 GB a day is 30.6 TB after 5 years, and that number arrives whether or not anybody planned for it.
Unfurls as a card showing these numbers. Nothing you typed is included.
The point of an estimate is not to be right. It is to be right about the order of magnitude, fast, out loud, while somebody is watching. An interviewer asking you to design a photo service does not want 4,271 QPS. They want to hear you say roughly five thousand, and then reason about what five thousand implies.
Three habits do most of the work. Round aggressively, because precision you did not earn is a lie that costs you time. Use 86,400 seconds in a day, or 100,000 if you are moving fast and the error does not matter. And separate reads from writes early, because they scale by completely different means: reads go to caches and replicas, writes go to sharding and queues.
Watch the replication factor especially. It is the multiplier people skip, and it is the difference between a storage answer that sounds reasonable and one that is off by three times before you have even started.
Questions people arrive with
- How do I estimate queries per second from daily active users?
- Daily users times requests per user, divided by 86,400 seconds. A million users making thirty requests a day is about 350 requests per second on average. Then multiply by three to five for peak, because traffic is never flat. The calculator above shows every step of the arithmetic.
- What is back-of-the-envelope estimation in system design?
- Turning a user count into the numbers that decide an architecture: requests per second, storage growth, and bandwidth. It is the first thing a system design interview asks for and the first thing a real capacity plan needs. Being within an order of magnitude quickly beats being exact slowly.