How to Approach Any System Design Interview (A Repeatable Framework)
Loading…
Loading…
Most candidates fail system design interviews not because they lack knowledge, but because they have no repeatable structure. They jump straight to databases and load balancers, skip requirements, and run out of time before the interesting trade-offs. This is the framework strong candidates use to stay in control of the conversation from minute one.
The interview is not a quiz with a correct answer. It is a simulation of how you'd lead a design discussion on the job: clarify the problem, propose something reasonable, and reason about trade-offs out loud.
Spend the first third of the interview on steps 1–3. They are where most candidates lose points, and they are the cheapest points to win.
Separate functional requirements (what the system does) from non-functional ones (how well it does it). Ask:
Write the agreed scope somewhere visible. Interviewers reward candidates who narrow an open-ended prompt into a concrete problem.
Back-of-the-envelope numbers anchor every later decision. Estimate reads vs. writes, requests per second, storage per year, and bandwidth. You don't need precision. You need the right order of magnitude so you can justify caching, sharding, or a CDN later. A read-heavy 100:1 system is a very different design from a write-heavy one.
List the core endpoints (or events) and the main entities with their key fields. This forces the abstract problem into something concrete and exposes hidden requirements early. It's far cheaper to discover a missing field now than during a deep dive.
Draw the boxes: clients, load balancer, application services, datastores, caches, queues. Walk one request end-to-end. Keep it simple first. A correct simple design beats a complicated one you can't defend. Only add components when you can name the problem they solve.
The interviewer will steer you into one or two areas: the data model, a hot path, consistency, or a bottleneck from your scale estimate. This is where senior signal is earned. Discuss concrete trade-offs, SQL vs. NoSQL, strong vs. eventual consistency, sync vs. async, and state which you'd pick and why for this problem.
Proactively name the weak points: single points of failure, the component that breaks first under 10× load, and how you'd monitor and scale it. Naming your own design's limits is one of the strongest signals you can send.
| Dimension | Weak signal | Strong signal |
|---|---|---|
| Problem framing | Starts designing immediately | Clarifies scope and constraints first |
| Trade-offs | "I'd use Kafka" | "Kafka because we need durable, replayable writes at this rate" |
| Communication | Silent diagramming | Narrates decisions, invites feedback |
| Depth | Stays shallow everywhere | Goes deep where it matters |
| Scoping | Tries to design everything | Prioritises the core path under time pressure |
The pattern: breadth first, then depth where it counts, narrating throughout.
Reading frameworks is necessary but not sufficient. The skill is doing it out loud, under time pressure, while someone probes your weak spots. Work through specific problems next: see our walkthrough of designing a URL shortener, then run a full timed mock so the structure becomes automatic. Pricing and bundles are on the pricing page.