Question 2 · Track 1 · How to run the interview
Back-of-the-envelope estimation
If you cannot size it, you cannot design it.
How to run the interview. 4 clarifying questions to ask first, the answer in 4 moves, the follow-up that catches a memorised answer and 2 supporting topics to watch or read.
What it is really testing
Whether your architecture is a consequence of numbers or a shape you memorised.
Ask these first
Before a single box goes on the board. The answers change the design, which is the point of asking out loud.
- Daily active users, and how many actions each?
- How peaky is the traffic — is there a spike hour?
- How big is one object, and how long do we keep it?
- How many copies of the data do we need?
The answer, in 4 moves
In this order. Each move earns the next one — say them out loud rather than drawing all four and narrating afterwards.
- 1Average QPS = daily actions ÷ 86,400. Say the arithmetic out loud.
- 2Peak is 2–10× average — pick a multiplier and justify it.
- 3Storage = objects/day × size × retention × replicas.
- 4Bandwidth = QPS × payload. Then say which of these four numbers hurts.
The trap
The follow-up that separates a rehearsed answer from a real one.
The point is not precision, it is which number changes the design. If storage is 40 GB you do not need a distributed store; if it is 40 PB nothing else you say matters. Quote the number, then use it in the next sentence.
Watch or read
The pieces of this answer, each covered on its own. Take them whichever way suits you, then give the whole answer without looking.
Latency vs throughput
Latency and throughput both measure performance, but they answer different questions: how long ONE request takes versus how MANY you can serve per second. Here's the difference that actually helps you debug — milliseconds and p99 tail latency, RPS/QPS capacity, Little's Law, why pushing utilization toward 100% makes latency explode, and how the same trade-off shows up in LLM serving.
Horizontal vs vertical scaling
Your app is slowing down under load — do you scale up or scale out? Vertical scaling means moving to a bigger machine: same app, same code, more CPU/RAM/disk. Horizontal scaling means adding more machines behind a load balancer. Here's how they really differ on cost, ceiling, fault tolerance, and the coordination tax — with a clear rule for which to reach for, plus how the same trade-off shows up when you serve LLMs.
Part of System Design Interviews, Answered Out Loud. The fundamentals underneath it are the free CS course.