// Free tool · Runs in your browser
System design capacity estimator.
The estimation step of a system design round, done with the working shown: QPS, storage, bandwidth, and cache size from a few assumptions. Change any number and the link updates, so you can share the result.
// 01 · Calculator
Run the numbers
Estimate · Working shown
Requests
- Requests a day
- 100M
- Writes a day
- 990K
- Reads a day
- 99M
20M users × 5 requests = 100M
100M ÷ (100 reads + 1 write) = 990K
100M − 990K writes = 99M
QPS
- Write QPS, average
- 11.5/s
- Write QPS, peak
- 34.4/s
- Read QPS, average
- 1,150/s
- Read QPS, peak
- 3,440/s
990K ÷ 86,400 s = 11.5/s
11.5/s × 3 peak = 34.4/s
99M ÷ 86,400 s = 1,150/s
1,150/s × 3 peak = 3,440/s
Storage
- New data a day
- 495 MB
- After 1 year
- 181 GB
- After 5 years
- 903 GB
990K writes × 500 B = 495 MB
495 MB × 365 days = 181 GB
495 MB × 1,825 days = 903 GB
Bandwidth
- Incoming, average
- 5.73 KB/s
- Incoming, peak
- 17.2 KB/s
- Outgoing, average
- 573 KB/s
- Outgoing, peak
- 1.72 MB/s
11.5/s × 500 B = 5.73 KB/s
5.73 KB/s × 3 peak = 17.2 KB/s
1,150/s × 500 B = 573 KB/s
573 KB/s × 3 peak = 1.72 MB/s
Cache
- Cache for 80% of reads
- 9.9 GB
99M reads × 500 B × hottest 20% = 9.9 GB
1 KB = 1,000 bytes. Cache size assumes an 80/20 spread (the hottest 20% of items get 80% of reads) and sizes the cache from one day of reads. Replication, indexes, and media files aren’t included.
Next step
Defend these numbers to an interviewer
Practise a system design round out loud with an AI interviewer that asks where your numbers came from and what breaks first at peak. Sign-up comes with 20 free credits.
// 02 · Guide
Estimating in a system design interview
Estimates come after requirements and before the high-level design. Their job is to give your choices a basis: you add a cache because reads outnumber writes a hundred to one, not because caches are standard.
Interviewers rarely check your arithmetic to the digit. They look at whether your assumptions are reasonable, whether you can move between per-day and per-second quickly, and whether the numbers show up again later in the design.
01
Say your assumptions
Daily users, requests per user, the read/write split, and item size. Round them hard and say them out loud so the interviewer can correct one before you build on it.
02
Turn a day into seconds
A day is 86,400 seconds; call it 100,000 in your head. 1M requests a day is about 12 a second, 1B a day about 12,000. Then multiply by a peak factor, because systems are sized for the busy hour.
03
Size what you keep
Writes a day × item size × days kept. Do one year and five, so you can say when a single database stops being enough, and leave room for replicas and indexes.
04
Tie each number to a choice
A number only matters when it changes the design: whether reads need a cache, whether storage needs sharding, whether a single region holds up at peak. Say which choice each one supports.
// 03 · From the blog
Read more on system design
- How to choose an AI mock interview platformCompare AI mock interviews, peer practice, and coding tools by the skill you need to train, then build a practice stack for the role you want.
- What Technical Interviews Evaluate in 2026What each round of a 2026 software engineer interview loop looks for: coding, system design, deep dives, AI use, and behavioral judgment.
- How to Tailor Your CV for AI Mock InterviewsWrite CV bullets that show scope, decisions, and evidence, so an AI mock interview probes the work you will actually be asked to defend.
// 04 · Player 1
Get ready for hard mode.
Paste the job you want. Run the loop until the real one feels like a rematch.
20 free credits · No card required