How to Approach Any System Design Interview (The 6-Step Framework)

🟠 Senior · interview-focused

A system design interview feels terrifying because it's open-ended — "Design YouTube" could go a thousand directions, and the blank whiteboard just stares back. Here's the secret the people who pass know: you're not being tested on whether you've memorised YouTube's architecture. You're being tested on whether you can drive a vague problem to a working design, out loud, making sensible trade-offs. This article gives you the exact 6-step framework to do that — the same one for every question — so you never freeze at the whiteboard again. If you're brand new, read scaling from zero to millions first; it gives you the building blocks this framework arranges.

The 6-step framework (memorise this order)

Step 1 — Clarify requirements (never skip this)

Jumping straight to drawing boxes is the #1 way to fail. First, pin down the scope. There are two kinds:

Functional requirements — what the system does. For "design Twitter": can users post tweets? follow others? see a timeline? like/retweet? Pick the 2–3 core features to focus on and explicitly park the rest ("I'll leave DMs out of scope for now — okay?").

Non-functional requirements — the qualities that shape the architecture: how many users? read-heavy or write-heavy? how important is consistency vs availability? latency expectations? These drive every later decision, so ask them now:

• Scale — "Roughly how many daily active users are we designing for?"
• Read/write ratio — "Is this read-heavy like a news feed, or write-heavy?"
• Consistency — "If two people see slightly different data for a second, is that okay?" (This is the CAP theorem question in disguise.)

Why it matters: designing for 1,000 users and 1 billion users are completely different systems. Getting the scale on the table now stops you from over- or under-engineering.

Step 2 — Back-of-the-envelope estimation

You don't need exact numbers — you need the right order of magnitude, because it tells you whether one database is fine or you need 100. Do the quick math out loud:

// Example: 100M daily active users, each posts 2 tweets/day
writes/day  = 100M x 2      = 200M tweets/day
writes/sec  = 200M / 86400  ≈ 2,300 writes/sec (avg)
peak        ≈ 2x avg        ≈ 4,600 writes/sec
reads       = 100x writes (read-heavy) ≈ 230k reads/sec
storage/day = 200M x 300 bytes ≈ 60 GB/day ≈ 21 TB/year

Now you know: 230k reads/sec means you need caching and read replicas; 21 TB/year means you'll shard. The numbers justify your architecture. Keep the standard latency numbers handy, and see estimation for the full method.

Step 3 — Define the API

Nail the contract between client and server before designing internals. It forces clarity about what the system actually offers:

POST /tweets            { text }            -> { tweetId }
GET  /users/{id}/feed   ?cursor=...          -> { tweets[], nextCursor }
POST /users/{id}/follow { targetUserId }     -> 200 OK

Notice the cursor for pagination (never "page numbers" at scale) and clean resource naming. REST is the safe default; mention gRPC or GraphQL if the problem calls for it.

Step 4 — Data model

What are the core entities, and how do they relate? For Twitter: User, Tweet, Follow. Sketch the tables/collections and their keys. Then make the big call: SQL or NoSQL? Justify it — "relationships and transactions matter here, so relational," or "massive write volume with simple lookups, so a wide-column NoSQL store." This is also where you decide your sharding key if scale demands it.

Step 5 — High-level design (draw the boxes)

Now, and only now, draw the architecture. Start simple and let the requirements pull in each component. A typical read-heavy system:

Walk the interviewer through a request: "A read hits the load balancer, goes to an app server, which checks the cache first, falling back to a read replica. A write goes to the primary DB and drops a job on the queue for slow work like fanning out to followers." Narrate the flow — that's what scores.

Step 6 — Deep dive & bottlenecks

The interviewer will now zoom in: "How does the timeline actually work at this scale?" or "What happens when the cache dies?" This is where senior candidates separate themselves. Show you can:

• Find the bottleneck — "230k reads/sec will crush the DB, so the timeline must be cached / precomputed."
• Handle failure — "If a cache node dies, reads fall back to the DB; we use consistent hashing so only a fraction of keys move." (See resilience patterns.)
• State trade-offs out loud — "Fan-out-on-write makes reads fast but writes expensive for celebrities with 100M followers, so we use a hybrid." There's rarely one right answer; naming the trade-off is the answer.

What interviewers are actually scoring

Not the "correct" design (there isn't one). They're scoring: Did you clarify before diving in? Did you communicate and think out loud? Did you justify decisions with the requirements/numbers? Did you drive the conversation instead of waiting to be led? Did you handle trade-offs and failure like someone who's run real systems?

The mistakes that fail people

• Drawing boxes before clarifying requirements — you'll design the wrong thing.
• Going silent — the interviewer can't score thoughts they can't hear.
• Over-engineering — don't shard a system for 1,000 users. Match complexity to scale.
• Ignoring the interviewer's hints — "what if this fails?" is a nudge, not small talk. Follow it.
• No numbers — "we'll add caching" is weak; "230k reads/sec needs caching" is senior.

Practice this framework on a real problem

Reading it isn't enough — run the 6 steps end to end on one design until it's muscle memory. The perfect starter is designing a URL shortener: small enough to finish, rich enough to touch every step. Then try a news feed.

Here's what changed everything for me: I stopped trying to know the answer and started trusting the process. The first time I hit "Design Uber" cold, I didn't panic — I just said "let me start with requirements," and the framework carried me. Ten minutes in, a design I'd never seen before was taking shape on the board, and the interviewer was nodding. That's the whole trick: you don't memorise a thousand systems, you memorise one framework and apply it live. Drill it on three or four designs, always out loud, always with numbers, and you'll walk in calm — because whatever they ask, you already know your first sentence. And that confidence is exactly what they're hiring for. You've got this.

What to read next

• Design a URL Shortener — apply all 6 steps start to finish
• Back-of-the-Envelope Estimation — Step 2 in depth
• SQL vs NoSQL — nail Step 4
• ← Back to the full System Design guide

← Scaling to millions · Design a URL shortener →