Structuring Your Answer

The five phases

Every strong system design answer, regardless of the prompt, moves through the same five phases in roughly the same order: clarify what you are actually building, estimate how big it needs to be, sketch a high-level design that satisfies both, pick one or two components and go deep, then step back and discuss trade-offs and what breaks under failure. Skipping a phase is the single most common way strong-on-paper candidates underperform — designing before clarifying produces a system that solves the wrong problem confidently; skipping trade-offs entirely produces a diagram with no evidence of judgment behind it.

None of this is exotic. It maps almost exactly onto how a real architecture review works at a company that runs them well: someone proposes a design, the room asks what problem it solves and at what scale, the design gets sketched, someone drills into the part that actually matters, and the meeting ends debating trade-offs and failure modes. The interview is a compressed, single-person version of that meeting — which is also why interviewers reward candidates who run it like one.

1. Clarify requirements (5-7 minutes)

Every system design prompt is deliberately underspecified — that is the point, not an oversight. "Design a URL shortener" could mean a single-region toy with a million users or a globally distributed service handling billions of redirects a day, and those are almost entirely different systems. Asking sharp clarifying questions before designing anything is the first and easiest signal of seniority, because it demonstrates you know the design depends on constraints you do not have yet.

Two categories of questions matter here, and strong candidates ask both:

• Functional scope — what does the system actually need to do, and just as importantly, what is explicitly out of scope. For a URL shortener: do custom aliases matter, do links expire, is analytics on click counts required.
• Non-functional constraints — the numbers that actually shape the architecture: read/write ratio, latency targets, consistency requirements, and rough scale (users, requests per second, data volume). A system that tolerates eventual consistency and one that requires strong consistency are different systems even if the functional requirements are identical.

Write the agreed scope down (out loud, and on the whiteboard if there is one) before moving on — it anchors the rest of the answer and makes it obvious to the interviewer that later decisions trace back to something you established early, rather than being invented on the spot.

2. Estimate scale (3-5 minutes)

A back-of-envelope capacity estimate is not about arriving at a precise number — it is about demonstrating that your design decisions later are grounded in a number, any reasonable number, rather than vibes. The standard chain is: daily active users → requests per user per day → requests per second (mean and peak) → storage growth per day → storage after N years. State an assumption for each unknown explicitly ("let's assume a 10:1 read/write ratio") rather than picking one silently — the assumption is part of what is being graded, not just the arithmetic.

The concrete payoff of doing this early: a design decision you make in phase three ("we need a cache", "we need to shard") should trace back to a number from phase two. A candidate who proposes sharding for a system that peaks at 50 requests per second is optimizing for a scale nobody asked for, and a sharp interviewer will ask why.

3. High-level design (10-12 minutes)

Sketch the major components and how data flows between them, at the level of a whiteboard diagram: client, API layer, the core service or services, a data store, and whatever sits between them (a cache, a queue, a CDN) that the scale estimate from phase two actually justifies. This phase should move quickly and stay high-level — the goal is a design that visibly satisfies the requirements from phase one at the scale from phase two, not a finished implementation. Resist the pull to go deep on any one box yet; that is phase four, deliberately separated so the interviewer can see you have a complete picture before you narrow in on any one part of it.

4. Deep dive (10-15 minutes)

Pick the one or two components where the interesting decisions actually live — usually wherever the scale or consistency requirement from phase one and two creates a real trade-off — and go deep: the data model and its indexes, the algorithm behind a non-trivial piece of logic, exactly how a cache is invalidated, how a queue provides backpressure. This is where most of the technical signal in the interview actually comes from, and it is also where interviewers most often steer the conversation with follow-ups ("what if two requests hit that endpoint at the same time", "what happens if that node goes down mid-write") — treat those as the interview working as intended, not as the interviewer trying to catch you out.

5. Trade-offs and failure modes (5-8 minutes)

Close by stepping back from the specific design and naming what you gave up. Every non-trivial system design decision trades something for something else — consistency for availability, latency for cost, simplicity for scalability — and a candidate who can articulate the trade-off explicitly ("we chose eventual consistency here, which means a user might briefly see a stale count, and we accepted that because...") reads as far more senior than one who presents the chosen design as the only reasonable option. Also volunteer at least one failure mode unprompted: what happens if the cache goes down, what happens if a region becomes unreachable, what the system does under a traffic spike well past the estimate from phase two.

Phrases that signal seniority

Interviewers pattern-match on language almost as much as on content. A few habits worth deliberately building:

• Name the trade-off before being asked: "I'm choosing X here, which costs us Y, because Z matters more for this use case."
• State assumptions instead of silently picking them: "I'll assume writes are much less frequent than reads — tell me if that's wrong."
• Reference the numbers from your own estimate when justifying a decision, rather than justifying decisions in the abstract.
• Acknowledge a follow-up as a real constraint rather than defending the original answer reflexively — "good point, that changes things, here's how I'd adjust."

None of this replaces technical depth — a candidate with perfect structure and no substance still fails. But a candidate with real technical depth and no structure routinely scores worse than their knowledge would predict, which is exactly why this page exists ahead of either problem walkthrough: Design a URL Shortener and Design a Rate Limiter both apply this exact structure end to end.