Back of the envelope math
About eight minutes into a system design round, the interviewer asks how much traffic this thing has to take. What they are checking is not your arithmetic. They are checking whether the design you are about to draw is a response to a number or a response to a blog post you read.
There are only three numbers worth computing, and each one buys you a specific decision.
A service has 10 million daily active users who each make 20 requests a day. Roughly what is the average requests per second, and what would you guess the peak is?
The only trick you need
Seconds in a day is 86,400. Round it to 100,000, which is 10^5. Now every traffic calculation is subtraction of exponents, and you can do it out loud without a whiteboard.
10 million users times 20 requests is 200 million requests a day. That is 2 x 10^8.
Divide by 10^5 and you get 2 x 10^3, so 2,000 requests a second. You just rounded
86,400 up by 16%, which makes your answer 16% low, and nobody in the room cares. What
they care about is that you got to a number in nine seconds.
Say “call it 100,000 seconds in a day” out loud. It signals that you know the real number and chose to drop it. Saying “86,400” and then reaching for a calculator signals the opposite.
Number one: requests per second
Design for the peak, not the average. A system sized for 2,315 rps falls over every evening at eight.
The peak multiplier is the part people skip. Traffic is not flat. A consumer app in India does most of its work between 8pm and 11pm, so three times average is a reasonable starting guess and you should say why you picked it. A B2B tool concentrated in one working day is worse, closer to five. A system that everyone hits at the same instant, a ticket sale or a match starting, does not have a multiplier at all. It has a spike, and that is a different design problem.
Number two: storage
Storage is where candidates spend too long and get too little credit. It is a multiplication, and the only judgement in it is the size of one record.
The raw number is the one people quote and the replicated number is the one that shows up on the bill. Say both.
Two multipliers that almost nobody applies out loud, and both of them earn a nod: indexes add something like 30% on a normal relational schema, and replication multiplies everything by three. Fifty terabytes of raw data is two hundred terabytes of disk.
Number three: bandwidth
Peak requests per second times bytes per response. That is it. It matters in exactly two situations: when you are serving media, and when you are fanning one write out to many readers.
Ten thousand image requests a second at 200KB each is 2GB a second, or 16 gigabits. That is a real cost and a real reason to put a CDN in the drawing. Ten thousand JSON responses a second at 2KB each is 20MB a second, which is nothing, and computing it was a waste of forty seconds you could have spent on the data model.
The numbers you should not have to derive
Guess each one before you reveal it. The ones you get wrong by more than 10x are the ones worth writing down.
What not to compute
| Choice | What you gain | What you pay | Pick it when |
|---|---|---|---|
| Peak requests per second | Sizes the stateless tier and tells you whether you need a cache at all. | Thirty seconds. | Always. This is the number the rest of the round hangs off. |
| Total storage over the retention window | Decides whether one database is enough or you are in sharding territory. | Thirty seconds, and a guess at record size. | Always, but keep it to one line. Nobody has ever failed a round for a wrong record size. |
| Bandwidth | Justifies a CDN and exposes fan out costs. | Twenty seconds. | Media, or one write read by many. Skip it for a JSON API and say why you skipped it. |
| Memory for the cache | Turns "add a cache" into "add 40GB of cache", which is a different sentence. | A guess at the hot fraction, usually 20%. | Read heavy systems, once you have already decided a cache belongs. |
Things not on that list: CPU cores, thread counts, connection pool sizes, exact disk IOPS. They depend on details nobody has in a 45 minute conversation, and reaching for them reads as someone filling time rather than someone making a decision.
Interview replay
This is the one page where the replay is not about a design. It is about doing arithmetic out loud without losing the room.
Checkpoint
1. 10 million daily users at 20 requests each. What is the average requests per second?
2. You compute 50TB of raw data. What number should you actually quote to the interviewer?
3. Your API returns 2KB JSON responses at a peak of 8,000 requests a second. How much time should you spend on the bandwidth calculation?
- 100,000 seconds in a day. Round it, say out loud that you rounded, and move on.
- 1 million a day is about 12 a second. 1 billion a day is about 12,000 a second. Two anchors cover most questions.
- Memory 100ns, SSD 100us, same datacentre round trip 500us, cross continent 150ms. Four latencies, four orders of magnitude.
- A factor of two is close enough. These numbers choose between architectures, not purchase orders.
I would start with peak requests per second, because that sizes the stateless tier and tells me whether I need a cache. Daily active users times requests per user, divided by a hundred thousand seconds, times a peak multiplier of about three for a consumer app. Then storage: records per day times record size times retention, and I would quote the number with indexes and three replicas because that is what you actually buy. Bandwidth only if we are serving media or fanning out. I would not compute CPU or connection pools in a design round, since those depend on details we do not have here.
