free tool · no sign-up
Capacity Estimator for system design interviews
How many requests a second? How much disk in a year? How many servers? Type in five numbers about your system. Every answer comes with its sum written out in plain words, so you can say it in an interview.
It starts with the URL shortener from our course: 100 million new links a month, 100 reads for every write.
Requests per second
3,935 / sec
peak about 11,806 / sec
20 million users × 17 requests each = 340 million requests a day.
A day has 86,400 seconds. 340 million ÷ 86,400 = 3,935 a second on average.
Traffic is not flat. At the busiest moment, 3 times that: 11,806 a second.
Reads and writes
3,896 reads / sec
39 writes / sec
A ratio of 100:1 means 100 of every 101 requests read data and 1 save new data.
Reads: 3,935 × 100/101 = 3,896 a second. Writes: 39 a second (3.37 million a day).
At peak: 11,689 reads and 117 writes a second.
Storage
614 GB / year
1.68 GB a day · 3.07 TB over 5 years
Only writes add data. Each write saves one item of 500 bytes.
3.37 million writes × 500 bytes = 1.68 GB a day.
× 365 days = 614 GB a year. × 5 years = 3.07 TB.
Databases usually keep 3 copies of the data so one broken disk loses nothing. Then the real disk you buy is about 3 times this: 9.22 TB.
Bandwidth
15.6 Mbps out
peak 46.8 Mbps · 156 Kbps in
Each read sends one item back to the user: 3,896 × 500 bytes = 1.95 MB a second going out.
Network speed is counted in bits, and 1 byte is 8 bits, so that is 15.6 Mbps (46.8 Mbps at peak).
Each write brings one item in: 39 × 500 bytes = 156 Kbps coming in.
Cache memory
33.7 GB
to keep the busiest reads in memory
A common rule of thumb: about 20% of the data gets about 80% of the reads. Keep that 20% in a fast memory cache such as Redis.
337 million reads a day × 20% × 500 bytes = 33.7 GB. This is the most you need: many reads ask for the same item, so the real number is usually smaller.
App servers (rough)
12 servers
13 with one spare
Size for the busiest moment, not the average: 11,806 requests a second ÷ 1,000 per server = 12 servers (always rounded up).
Add at least one spare, so one server can fail or restart and users notice nothing: 13.
Units: 1 KB = 1,000 bytes, 1 MB = 1,000 KB, 1 GB = 1,000 MB, 1 TB = 1,000 GB. Round numbers are fine in an interview; the method is what the interviewer checks.
Want to know what to do with these numbers? The System Design course teaches it step by step, and the URL shortener lesson uses these exact defaults.
How to use it in an interview
Ask for the numbers
Ask the interviewer how many daily users and what the read to write ratio is. If they say "you decide", pick round numbers and say them out loud.
Do the sums in order
Requests per second first, then storage, then bandwidth. Write each sum on the board the way this tool writes it, so the interviewer can follow.
Let the numbers choose the design
Thousands of reads a second for a few hundred bytes each points to a cache. Terabytes a year points to splitting the data across machines. Say which number made you choose.
Questions people ask
What is a back-of-the-envelope estimate?
It is a quick sum with round numbers, done in a few minutes, to find out how big a system has to be. In a system design interview it tells you whether one database is enough or whether you need many machines, before you draw anything.
How do I turn daily users into requests per second?
Multiply daily active users by the requests each one makes in a day. That gives requests per day. Divide by 86,400, the number of seconds in a day, to get the average per second. Traffic is not flat, so multiply by 2 or 3 for the busiest moment.
Why does the read to write ratio matter?
Writes save new data, so they decide how fast storage grows. Reads only look at data that is already there, so they decide how much cache and how many servers you need. A URL shortener is read about 100 times for every write, which is why it leans on a cache.
How do I estimate storage?
Multiply writes per day by the size of one saved item. That is storage per day. Multiply by 365 for a year, then by the number of years you keep the data. Databases usually keep 3 copies, so the disk you buy is about 3 times that.
How many servers do I need?
Divide the requests per second at the busiest moment by how many requests one server can answer in a second, and round up. Then add at least one spare, so one server can fail without users noticing. Measure the per-server number with a load test on your own code; 1,000 a second is only a first guess.
Is 1 KB 1,000 bytes or 1,024 bytes here?
This tool uses 1,000, so 1 KB is 1,000 bytes and 1 GB is 1,000 MB. The difference is under 10 percent, which does not change any decision an estimate is used for.
How exact is this?
It is a first guess, not a promise. Being within 2 or 3 times of the real number is good enough to choose a design. In an interview the method matters more than the final digit, so say each step out loud.
Practise on a real question: the interview guides walk through the estimates for Twitter, WhatsApp and YouTube. Or see every interview guide.