System Design Interview Framework

Framework Overview

What it is, and why it matters

System design interviews evaluate how you reason about ambiguous, large-scale technical problems — not whether you land on one "correct" architecture. The strongest candidates work through the problem in a visible, structured order rather than jumping straight to a diagram.

When To Use It

Where this framework applies

Senior and staff engineering interviews Architecture and infrastructure rounds Solutions architect client-scenario interviews Any open-ended "design a system that..." prompt

Framework Breakdown

How it works

1

Clarify Requirements

Ask what the system actually needs to do and for whom, before proposing anything.

2

Define Constraints

Establish scale, latency, consistency, and cost constraints explicitly.

3

High-Level Design

Sketch the major components and how data flows between them at a coarse level.

4

Deep Dive

Go deep on the one or two components the interviewer cares most about.

5

Trade-offs

Name the alternatives you didn't choose and why, showing you understand the cost of your decision.

6

Scale & Optimize

Discuss how the design evolves under 10x or 100x load, and where it would break first.

Worked Example

Seeing it applied

"For a URL shortener at scale, I'd first clarify: how many writes per second, do we need analytics, how long do links live? Given 10,000 writes/second and a read-heavy pattern, I'd propose a base62-encoded counter for ID generation behind a write-through cache, with reads served from a CDN-fronted key-value store. The deep dive would be on avoiding ID collisions across multiple writer nodes — I'd use a distributed counter service rather than random generation to avoid collision-retry overhead. The trade-off is added write latency for that lookup, which I'd accept because reads outnumber writes roughly 100 to 1 here."

Common Mistakes

What to avoid

Jumping straight to a solution before clarifying requirements
Ignoring explicit scale numbers and designing for an unstated assumption
Presenting one design with no discussion of alternatives or trade-offs
Over-engineering the initial design instead of starting simple and scaling deliberately

Preparation Checklist

Before you practise

Always start by asking 3–5 clarifying questions
State your assumptions about scale out loud before designing
Practise narrating trade-offs, not just the final design
Time-box the deep dive so you don't run out of time on trade-offs

Additional Resources

System Design