Loading...
Loading...
System Design · Practice
Back-of-the-envelope numbers that turn a design preference into a defensible argument.
The skill that turns an opinion into an argument.
Backend system design interviews have trained everyone to estimate QPS and storage. Frontend interviews ask the same thing and almost nobody prepares for it, which makes it one of the highest-leverage things you can practise.
The moment that separates a senior answer from a staff answer is usually not a cleverer architecture. It is the candidate who says "that is roughly 500,000 DOM nodes, so we cannot render this directly" instead of "we should probably virtualise." The first is a conclusion; the second is a preference.
Estimation is a script, not a talent. Run the same four steps every time.
Say it out loud before you compute anything: "I want to know whether one page of this feed fits in a 300ms budget on 3G." An estimate without a decision attached is trivia.
Break the unknown into factors you have intuition for: items per page, bytes per item, compression ratio, throughput. Guessing four small numbers is far more accurate than guessing one big one, because the errors partially cancel.
Use one significant figure. 1 KB per item, not 1.15 KB. You are looking for the order of magnitude, and rounding keeps the arithmetic speakable while you are also drawing on a whiteboard.
This is the step that earns the signal. "500 MB of DOM, so virtualisation is mandatory, not optional." The number is evidence; the decision is the answer.
Quoting these from memory is the cheapest credibility you can buy.
| Quantity | Value | Why it matters |
|---|---|---|
| One animation frame at 60fps | 16.7 ms | Exceed this and you drop a frame |
| INP 'good' threshold | 200 ms | Interaction to Next Paint, 75th percentile |
| LCP 'good' threshold | 2.5 s | Largest Contentful Paint, 75th percentile |
| Long task threshold | 50 ms | Anything longer blocks input |
| Perceived as instant | 100 ms | Below this, action feels direct |
| Attention held without feedback | 1 s | Beyond this you need a spinner |
| TLS handshake (new connection) | 1-2 RTT | TLS 1.3 is 1-RTT, 0-RTT on resume |
| DNS lookup (uncached) | 20-120 ms | Preconnect removes it from critical path |
| Same-region API call | 10-50 ms | Server processing excluded |
| Cross-continent round trip | 150-300 ms | Speed of light is the floor |
The two that do the most work in interviews are the 16.7ms frame budget and the 50ms long-task threshold. Almost every rendering and responsiveness argument reduces to one of them.
Enough to size an API response or a bundle without looking anything up.
| Quantity | Value | Note |
|---|---|---|
| Typical JSON record | ~200-500 bytes | Roughly 10-20 modest fields |
| Feed item with media metadata | ~1-2 KB | Before the media itself |
| Gzip on JSON | ~70-80% reduction | Brotli adds a few points more |
| React + ReactDOM (gzip) | ~45 KB | Before any application code |
| Median site JS payload | ~500 KB | Compressed, and far too much |
| Reasonable JS budget | ~170 KB | Compressed, for a 3s TTI on mid mobile |
| Hero image (well optimised) | ~50-150 KB | AVIF or WebP, correctly sized |
| Web font, one weight (woff2) | ~15-30 KB | Subset to the glyphs you use |
| DOM node cost | ~1-2 KB memory | Why virtualisation matters past ~5k nodes |
Treat every one of these as accurate to a factor of two. That is precise enough to rule designs in or out, which is all an estimate needs to do.
Derive the bundle budget instead of quoting it.
The widely-cited 170KB JavaScript budget is not a magic constant. It falls out of a target load time, a network profile, and how long a given device takes to parse each kilobyte. Change any input and the budget moves — which is exactly the reasoning an interviewer wants to see you perform.
Notice what happens when you switch from desktop to a low-end Android: the budget collapses even though the network is unchanged. On mobile the binding constraint is main-thread parse and compile time, not bandwidth. That single observation is worth more in an interview than any amount of memorised advice about code splitting.
Four estimates that each change a design decision.
No. This exceeds the memory budget of a mobile browser tab.
So what
Virtualise to roughly 30 visible rows plus overscan, which keeps the tree near 500 nodes. The estimate is what turns 'virtualisation is a nice optimisation' into 'virtualisation is the only viable design'.
Under 300 ms on Fast 3G. Acceptable, but the page size is at the limit.
So what
100 is a defensible page size. Going to 500 would push past a second on 3G, so if product wants larger pages the answer is cursor pagination with prefetch, not a bigger page.
Naive fan-out is 48k messages/sec, which will melt both the server and the clients.
So what
Batch edits into 50 ms windows before broadcasting. That cuts outbound traffic roughly twentyfold with no perceptible latency cost, and it is the single most important design decision in the whole system.
Roughly 170 KB compressed is the defensible target once you leave room for rendering and interaction.
So what
This is where the widely-quoted 170 KB budget actually comes from. Deriving it live is far more convincing than citing it.
How to run an estimate without stalling the conversation.
Estimating and then not using the result. Candidates regularly compute a payload size, say "so that is about 100KB," and move on. The interviewer is waiting for the next sentence — the one where the number rules something in or out. Without it, the whole exercise reads as arithmetic rather than judgement.
What to carry into the room.