System Design Fundamentals for Interviews: Scalability, Trade-offs, and the Framework Interviewers Actually Grade

Part 2 of 14 · ~4 min

What System Design Interviews Actually Test

Walk in assuming there's a hidden "correct" diagram and an interviewer silently scoring your attempt against it, and you've already misread the exercise. Two companies solving the identical problem — a ticketing platform, a chat app, a dispatch system for delivery drivers — routinely land on very different architectures, and both can be entirely defensible given what each team actually had to work with: their traffic shape, their team size, their deadline. What actually gets evaluated is closer to a job-sample test than a trivia quiz: can you turn an ambiguous prompt into real requirements instead of guessing, can you back a decision with an actual number instead of the word "scale," and can you say why you picked one trade-off over its alternative rather than presenting the diagram as though it arrived pre-approved.

The Five-Step Framework

There's a shape that works for almost any prompt, and it isn't interview trivia — it's the exact sequence that got Fanline's small team through a launch with nine days of runway and no time to redesign anything from a blank page.

1. Clarify requirements. Separate what the system has to do (functional) from the conditions it has to do it under — user counts, traffic, latency expectations, whether a number on screen has to be exactly right or just close enough. Skip this and everything you build afterward is answering a question nobody actually asked.
2. Estimate, roughly. Convert those requirements into numbers you can hold in your head — requests per second, data growth per year, how lopsided reads are compared to writes. This is the step that tells you whether one machine can carry the load or whether the whole conversation needs to be about distributing it.
3. Sketch the high-level shape. Clients, a load balancer, app servers, a cache, a database, maybe a queue — drawn coarsely, on purpose. The goal here is a shared mental picture everyone in the room agrees on before anyone zooms into a single box.
4. Go deep on the part that matters. Pick whichever piece is genuinely interesting for this problem — an ID scheme that can't be guessed, a rate limiter that survives more than one server — and actually work through it: the data structure, the algorithm, where it falls over. Trying to go deep on every box instead of one or two is its own failure mode, and the closing chapter below explains why.
5. Say what you didn't solve. Name the bottleneck, the single point of failure, the thing that breaks first under ten times today's traffic. A design that's presented as airtight is the red flag, not the reassurance — every real one has a soft spot, and naming yours reads as experience, not weakness.

Why the Process Matters More Than Any Single Diagram

Nothing about a cache sitting in front of a database, or a leader handing writes off to a pile of read replicas, is going to surprise someone who's sat through this interview fifty times — they've seen every popular shape already. What they're actually watching for is the path you took to get there. Whether a number from your own estimate ever shows back up in the design you drew, instead of getting calculated and then quietly ignored. Whether you flagged your own single point of failure before being asked about it, or had to be walked there one leading question at a time.

Which is also why "correct" is simply the wrong lens. Two people can hand in completely different diagrams and both pass, as long as each diagram is honest about the requirements it started from and each candidate can hold their ground when the interviewer pushes on a decision. And two people can hand in the same diagram and split — one pass, one fail — if one of them reasoned their way there and the other recited a shape they'd rehearsed the night before, because the follow-up questions expose that gap almost immediately.

Common mistake: treating whichever component you happened to study hardest as the one true subject of the interview, and steering every answer back there no matter what was actually asked. It reads instantly as rehearsed, and rehearsed is precisely the opposite of what this interview is trying to measure.