System Design Interviews
Clarify, estimate, sketch, then defend the trade-offs — a repeatable structure for an open-ended hour.
70 minDifficulty 4/5interview · architectureAI-writtenWritten by a model on 16 August 2026 and not yet read by a person. Checked automatically: schema, the pedagogical rules the hand-written material is held to, and every diagram parsed for real.
Before this
- Load Balancing — Spreading traffic across machines, and what breaks the moment there's more than one.
- Caching with Redis — An in-memory store used as cache, session bag, lock, counter, and queue.
- Message Queues — Hand the work to someone else and answer now — the backbone of every responsive backend.
- Data Modelling — Normalise until it hurts, denormalise until it works — and know which one you're doing.
Why this exists
"Design a URL shortener" is not actually a question about URL shorteners — it's an open-ended hour designed to see whether you can turn a vague prompt into a structured investigation: what does this system actually need to do, roughly how big does it need to be, what are the two or three components that matter most, and can you defend the tradeoffs in your choices under pushback. Candidates who jump straight to drawing boxes, without first pinning down scope, consistently run out of time having designed the wrong thing.
The mental model
A repeatable structure beats improvising from scratch every time: CLARIFY the actual requirements and scope (functional and non-functional), ESTIMATE rough scale (requests per second, data volume) to know what actually needs solving, SKETCH the major components and how data flows between them, then DEFEND the specific tradeoffs — why this database, why this caching strategy — under follow-up questions.
How it works
Clarifying scope first prevents designing the wrong thing entirely
"Design a URL shortener" could mean a simple redirect service, or one with custom aliases, analytics, expiring links, and abuse prevention — each implies a genuinely different design. Asking 'what specific features are in scope' and 'roughly how many users/requests are we designing for' in the first five minutes prevents spending the remaining fifty five designing a system that doesn't match what was actually being asked.
Back-of-envelope estimation grounds every later decision in a real number
100 million URLs shortened per month is roughly 40 requests per second on average, but a system needs to handle PEAK load, often several times the average — and this single number determines whether a single database instance is plausible or whether sharding is genuinely necessary from day one. Skipping estimation means every subsequent design choice is a guess rather than a decision grounded in an actual number.
Start with the simplest design that satisfies the requirements, then add complexity only where justified
A single application server plus a single database is a completely legitimate starting sketch for a moderate-scale system — jumping straight to microservices, multiple caching layers, and a message queue for a system that a single well-indexed database could actually handle signals over-engineering, not sophistication. Add each additional piece of complexity specifically to solve a bottleneck the ESTIMATED scale actually implies.
Every design choice needs a stated tradeoff, not just a stated choice
"I'll use a NoSQL database" invites the immediate follow-up 'why, specifically, over a relational one for this data?' — a strong answer names the actual tradeoff being made (schema flexibility vs. join support, given THIS system's access pattern), while a weak answer just restates the choice without justifying it against the alternative.
The mechanism
Clarifying scope establishes what's actually being asked for, avoiding wasted effort on the wrong problem. Estimation converts vague scale into concrete numbers that inform every later decision. Sketching lays out the major components — load balancer, application servers, database, cache — and how a request flows through them. Defending means being ready to justify any specific choice's tradeoff when challenged, and revising the sketch if a follow-up question reveals a constraint the design didn't account for.
flowchart LR C[Clarify: scope + requirements] --> E[Estimate: rough scale] E --> S[Sketch: major components + data flow] S --> D[Defend: tradeoffs under follow-up questions] D -.->|new constraint surfaces| S
What people get wrong
- The goal of a system design interview is to produce the single 'correct' architecture.
- There's rarely one correct answer — the interviewer is evaluating the STRUCTURE of your thinking (clarifying, estimating, justifying tradeoffs) far more than which specific technology you picked, and a well-reasoned simple design often scores better than an elaborate one with unjustified choices. Candidates who chase a mythical 'right answer' instead of demonstrating reasoning often perform worse than those with a simpler but clearly-justified design.
- Using more advanced, distributed-systems-sounding technology (microservices, Kafka, multiple caching tiers) signals seniority.
- Adding complexity the actual estimated scale doesn't justify signals the OPPOSITE of seniority — it suggests an inability to right-size a solution to actual constraints, which is precisely the judgment the interview is trying to assess. Interviewers specifically probe 'why do you need that' for every added component, and an answer amounting to 'it sounds more scalable' rather than a concrete, estimated justification is a common way candidates lose credibility.
- Spending the first several minutes clarifying requirements wastes valuable design time.
- Time spent clarifying scope UP FRONT is what prevents spending the majority of the remaining time designing something that doesn't match the actual ask — skipping it risks a much larger time loss discovered only near the end. This is exactly why 'clarify first' is the standard first step in every reputable system design framework — the apparent time cost is trivial compared to the cost of designing the wrong system.
When not to use it
- The interviewer explicitly states scope and scale upfront, leaving nothing to clarify.
- Move directly to estimation and sketching — the clarification step's VALUE, not the step itself, is what matters; if it's already been provided, restating it back briefly to confirm understanding is enough.
- You're asked to design something genuinely small and simple, where extensive estimation would be overkill.
- A lighter-weight pass through the same structure is fine — the framework scales down; a five-minute design doesn't need the same depth of estimation as an hour-long one.
Terms
- Functional requirements
- — What the system must actually DO — specific features and behaviours it needs to support.
- Non-functional requirements
- — Qualities the system must have beyond specific features — availability, latency targets, consistency guarantees.
- Back-of-envelope estimation
- — Rough, order-of-magnitude calculations of scale (requests per second, storage volume) used to ground design decisions in concrete numbers.
- Bottleneck
- — The specific component or resource that limits a system's overall capacity, which additional complexity should be justified against, not added speculatively.
In an interview
Walk through how you'd approach 'design a system to handle a flash sale with 100x normal traffic for 10 minutes'.
- clarify: which specific parts of the flow need to handle the spike (browsing vs checkout vs inventory) and what's an acceptable degraded experience
- estimate: convert '100x normal traffic' into an actual requests-per-second number to size the solution against
- sketch a design targeting the specific bottleneck this implies (likely inventory/checkout contention, not general browsing), rather than scaling everything uniformly
Can you recall it?
Why does starting with the simplest design that satisfies stated requirements demonstrate stronger engineering judgment than starting with an elaborate, distributed architecture?