The Four-Step System Design Interview Framework

01What This Page Is For

This is the framework spoke. The main guide introduced the four steps in summary. This page does the deep treatment: what each step looks like in practice, what good and bad examples sound like, what gets written down, and a full end-to-end walkthrough on a real interview question.

If you're new to the framework, read the four step sections below in order. If you already know the framework and want to see it applied, jump to the Twitter feed walkthrough. If you're prepping for an interview tomorrow, read the FAQ and skim the rest.

This page assumes you've read the main guide, especially Section 5 (What's Changed in 2026) and Section 9 (What Interviewers Actually Grade). The framework is scaffolding. The rubric is what gets graded. Knowing both is the difference between mechanical execution and effective communication.

02The Framework, Recap

Four steps, in the order you'll use them in a typical 45 to 60 minute interview:

1. Clarify and scope. Functional requirements, non-functional requirements, scale estimates. Roughly 5 to 10 minutes.
2. Data and API. What gets stored, what gets sent over the wire. Another 5 to 10 minutes.
3. High-level design. Boxes and arrows for the major components, with verbal narration of choices. The middle 15 to 20 minutes.
4. Deep dive and stress test. Two or three components in depth, then walk the design through failure modes and cost. The final 15 to 20 minutes.

The framework is not magical. It works because it matches how interviewers think about the conversation arc. They are checking, in this order: did the candidate scope the problem (Step 1), did they ground the design in concrete data and APIs (Step 2), did they commit to a high-level structure with defensible choices (Step 3), and could they go deep without breaking down (Step 4).

Rest of this page: each step in detail, then a worked example, then how the framework adapts for AI-adjacent questions, then practice guidance.

03Step 1: Clarify and Scope

The interviewer asks you an open-ended question. Your first move is not to design. Your first move is to make the question concrete.

Three things you're trying to establish: what features matter (functional requirements), what constraints matter (non-functional requirements), and what scale we're designing for (users, traffic, storage, geography). Spend real time here. Five clarifying questions is normal. Ten is fine. Zero is a red flag.

Functional requirements

Functional requirements are what the system does. Pick three to five core features. State them explicitly. Descope everything else.

The mistake most candidates make at this stage is trying to be comprehensive. The interviewer doesn't want exhaustive. They want focused. "We're designing the read and write paths for a basic feed, with follow relationships. We're not designing search, ads, DMs, or media at this stage. Are you OK with that scope?" That sentence is the move. It commits to scope and invites the interviewer to redirect if they wanted something different.

Non-functional requirements

Non-functional requirements are how well the system does it. The four that matter most: availability, latency, consistency, and durability. Pick targets. Pick them with the interviewer's input rather than guessing.

The trick at this stage is not to recite the four words. It's to commit to a target for each one and connect the target to a design implication. "We need 99.9% availability, which means we can tolerate roughly 8 hours of downtime per year. That rules out single-region active-passive. We probably need at least active-passive across regions." That sentence does triple duty: it states a target, it explains what the target means, and it implies a design direction.

Scale estimation

Scale estimation is back-of-the-envelope math. Round generously. Don't aim for precision. Aim for orders of magnitude that you can defend.

For Twitter: 200 million daily active users, each user writing 2 tweets per day on average and reading roughly 200 tweets per day. That gives 400 million writes per day (about 5,000 writes per second) and 40 billion reads per day (about 500,000 reads per second). Read-heavy by 100 to 1. That ratio alone determines a lot of the design.

What you should write down

By the end of Step 1, the whiteboard should have a small box in one corner labeled something like:

• Features in scope: post tweet, follow user, read home timeline
• Out of scope: search, DMs, ads, media, notifications
• Scale: 200M DAU, ~5K writes/sec, ~500K reads/sec, read-heavy 100:1
• Targets: 99.9% availability, p99 latency < 200ms for reads, eventual consistency OK

That box stays visible the entire interview. When the interviewer pushes you on a design choice, you can point to it and say "given the scale here and the read-heavy ratio, I'd choose X." The choice is grounded.

Common mistakes at Step 1

• Skipping clarification entirely. Drawing within 30 seconds. The most common loop-killer at every level.
• Asking too many feature questions, no scale questions. Functional requirements without scale don't constrain the design enough.
• Stating non-functional requirements as labels rather than targets. "We need it to be highly available" is meaningless. "We need 99.9%" is concrete.
• Spending 20 minutes here. The interviewer wants to see you scope quickly and start designing. Five to ten minutes is the budget.

04Step 2: Data and API

Before you draw the architecture, define what data the system handles and what API it exposes. This step is short but load-bearing. Skipping it is one of the most common reasons mid-level candidates fail to reach senior bar: their architecture floats abstractly without ever connecting to concrete data flows.

Data: entities and access patterns

List the major entities. Three or four is usually enough at this stage. For each, note rough size and the access patterns: read-heavy, write-heavy, mixed.

For Twitter:

• User (id, name, handle, profile metadata). Roughly 200 bytes per record. Mostly read.
• Tweet (id, author_id, text, created_at). Roughly 280 bytes plus metadata, call it 500 bytes per record. Write-once, read-many.
• Follow relationship (follower_id, followee_id). Tiny records. Read-heavy. Some users have millions of followers (the celebrity hot-key problem we'll come back to).

Note what you're explicitly not modeling. "I'm not modeling media, retweets, or quote-tweets at this stage. I'll add them if we have time at the end."

API: the four or five endpoints that matter

Sketch the API surface for the in-scope features. RESTful is fine. GraphQL is fine. gRPC is fine. The interviewer cares less about the protocol than about whether you can commit to one and defend it.

For Twitter's three in-scope features:

• POST /tweets body: { text } returns: tweet object
• GET /tweets/:id returns: tweet object
• POST /users/:id/follow body: { target_user_id }
• DELETE /users/:id/follow/:target_user_id
• GET /users/:id/timeline query: ?cursor=xyz&limit=50 returns: paginated tweets

Five endpoints. Two minutes per endpoint, max. If the interviewer wants more depth on a specific endpoint, they will say so.

Common mistakes at Step 2

• Designing a complete schema. You're sketching, not migrating. Three or four entities, key fields only.
• Designing 15 endpoints. The five most important. The interviewer will ask if they want more.
• Skipping access patterns. "Tweets are read-heavy 100 to 1" is a sentence that determines half your subsequent design choices. Say it out loud.
• Forgetting pagination. Any list endpoint needs a cursor strategy. Saying it explicitly is a signal of seniority.

05Step 3: High-Level Design

Now you draw. Boxes for components. Arrows for data flow. Labels for protocols. The goal is a single diagram that represents the system end-to-end at the level a tech lead could read in 30 seconds and understand.

The five-to-seven component rule

Five to seven major components is the right density at this stage. Fewer, and the design is too abstract to evaluate. More, and the diagram becomes unreadable.

Typical components for a read-heavy product like Twitter:

• Clients (web, mobile)
• Load balancer in front of the API tier
• API servers (stateless, horizontally scaled)
• Tweet write path: into a queue, then to a tweet store
• Timeline read path: from a timeline cache, fallback to assembly from tweet and follow stores
• Tweet store (sharded by author_id, often Cassandra or similar)
• Follow graph store (often a sharded relational store or graph database)
• Timeline cache (Redis, per-user precomputed timelines)

That's seven or eight, slightly over the five-to-seven target but acceptable for this question shape because the read and write paths diverge so significantly. Group related components on the diagram so the reader can see the structure.

Narration discipline

Every component you place is a choice. Briefly explain why it's there. Don't narrate every micro-choice; do narrate the load-bearing ones.

For Twitter specifically, the load-bearing choices are:

• Whether the timeline is precomputed (push model) or assembled at read time (pull model) or hybrid
• How tweets are stored and sharded (by author? by tweet ID? by time?)
• Whether reads hit a cache or assembly logic by default

Each of those deserves a sentence of explanation as you draw. "I'm using a hybrid fan-out: push tweets into followers' timelines for normal users, but for celebrities with more than 10 million followers, fall back to pull at read time. This avoids write amplification on celebrity tweets while keeping read latency low for the common case."

That sentence is the difference between a senior and a junior interview. Same diagram. Different signal.

What the whiteboard looks like at minute 25

Common mistakes at Step 3

• Drawing 15 components with no labels. The diagram is unreadable. Limit yourself.
• Not narrating choices. The diagram is half the signal. The narration is the other half.
• Polishing the diagram. Boxes don't need to be aligned. Time spent polishing is time not spent on content.
• Designing both read and write paths in equal detail. For read-heavy products, the read path is harder. Spend more time there.

06Step 4: Deep Dive and Stress Test

This is where senior loops are won or lost. The interviewer picks two or three components from your high-level design and asks you to go deeper. At staff level, you're expected to volunteer the deep-dive areas yourself rather than wait to be asked.

How to pick what to go deep on

Pick two or three components based on three criteria, in order: where is the most complexity, what would scale break first, and where is the interesting tradeoff. For Twitter, the obvious deep-dive candidates are:

• Timeline fan-out strategy (the push/pull/hybrid choice)
• Tweet storage and sharding (especially the celebrity hot-key problem)
• Read path under failure (cache misses, fallback assembly, latency budget)

Pick two. State that you're picking two. "I want to go deep on the fan-out strategy and the tweet storage. I'll touch on cache failures briefly at the end if we have time. Sound good?" Strong candidates volunteer this routing. Weak candidates wait for the interviewer to pick.

What "going deep" actually means

Going deep is not "explaining what each component does." Going deep is reasoning through the failure modes, the math, the operational reality. For each deep-dive area, you should be able to answer:

• What breaks first as we scale this up 10x?
• What's the cost at this scale, and what would cut it in half?
• What does the on-call engineer see when this fails, and how do they recover?
• What's the consistency model, and what corner cases violate it?

If you can answer those four questions for two components, you've done the deep-dive correctly. If you mention five components and can't answer those questions for any of them, you've gone wide instead of deep, which is a senior-bar miss.

Stress test patterns

After the deep dives, walk the design through failure modes. This is the stress test. Five questions worth running through:

1. What happens at 10x traffic? Which component breaks first? What would you do?
2. What happens when a region goes dark? Where's the durability boundary? How long until full recovery?
3. What happens when the cache fills up? Eviction strategy? Stampede risk?
4. What's the cost at this scale? Per-request, per-user-month, total infrastructure. Where would you cut?
5. What's the on-call burden? What pages? What's the runbook?

You don't need to walk through all five for every component. Pick the two or three most relevant for each of your deep-dive areas. For Twitter's fan-out, the 10x traffic question and the cost question are the highest-leverage. For the tweet store, the region-goes-dark question and the consistency model are the loadbearing ones.

Common mistakes at Step 4

• Going wide instead of deep. Touching every component shallowly. The single biggest senior-bar miss in this step.
• Hedging instead of committing. "It depends" three times in a row reads as evasion. Pick something.
• Skipping the stress test. Designing without ever asking "what breaks?" is a junior pattern.
• Skipping cost. 2026 senior loops grade this explicitly. Even one sentence about cost is enough.
• Skipping operational concerns. Monitoring, deployment, rollback. If you never said those words, you've left rubric points on the table.

07Worked Example: Design Twitter's Feed

What follows is a representative end-to-end walkthrough of a 50-minute system design interview using the framework. The candidate is targeting a senior role. The interviewer is from a FAANG-tier company. The question is the classic: design Twitter's feed.

This is not the perfect answer. There is no perfect answer. This is a defensible answer that shows what the framework looks like in practice, including the moments where the candidate explicitly descopes, hedges productively, and commits when challenged.

What this walkthrough modeled

Notice what the candidate did and didn't do. They:

• Spent 8 minutes scoping before drawing anything
• Descoped explicitly: search, DMs, ads, media, ranking
• Committed to specific technologies (Redis, Cassandra) without belaboring
• Volunteered the deep-dive areas before being asked
• Engaged productively with pushback rather than getting defensive
• Closed with cost and operations even though those weren't explicitly requested

What they didn't do: enumerate every possible feature, mention every technology they'd ever heard of, polish the diagram, hedge through "it depends," or skip operational concerns. The interview was 50 minutes. Most of that time was the candidate talking. The interviewer interrupted twice and got engaged responses both times.

This is what the framework looks like when run well. Not flashy. Not exhaustive. Defensible, focused, and operationally aware.

The interview was 50 minutes. The candidate talked for 40 of them. The interviewer interrupted twice and got engaged responses both times. That's the loop.

08What Changes for AI-Adjacent Questions

The framework is the same. What shifts is what you ask in Step 1, what you draw in Step 3, and what you go deep on in Step 4.

Step 1: clarification adds AI-aware questions

If the question allows for an AI angle, ask about it during clarification. The AI-aware version of the Twitter scoping above might add: "Are we serving any LLM-generated content on top of the feed? Generative summary, AI-suggested replies, anything in that space? What's the latency budget for the model call if there is one?"

Even if the answer is "no, ignore that for now," you've signaled current-era awareness, which is graded explicitly in 2026 senior loops.

Step 3: the architecture grows an AI tier

The classic stack stays the same. What's new is the AI tier sitting alongside it. For a question like "design a recommendation feed with an LLM-generated summary at the top," the high-level diagram now needs:

• An LLM gateway (rate limiting, fallback handling, response caching)
• A vector store for retrieval-augmented context
• An embedding pipeline that processes new content into the vector store
• Latency-aware routing (the LLM call has a much larger latency budget than the rest of the read path)

These are additional components, not replacements. Most candidates still draw the classic stack and bolt on the AI tier as a parallel path. That's fine. What's not fine is omitting the AI tier entirely when the question implies it.

Step 4: deep dives shift toward AI-specific operational concerns

For AI-adjacent questions, the deep-dive list grows:

• Token cost reasoning: how many LLM calls per user per day, at what cost per million tokens, with what caching strategy?
• Latency strategies: when the model call takes 800ms, how does the rest of the read path stay under the budget?
• Fallback behavior: when the model is degraded or unavailable, what does the user see? Cached response? Default ranking? Graceful skip?
• Vector store maintenance: re-indexing as embeddings drift, hybrid keyword-plus-semantic ranking, recall-versus-latency tradeoff.

These topics are mostly absent from older guides. They are now mainstream in 2026 loops at AI-first companies and increasingly at FAANG companies that have shipped AI features. Practice them specifically if you're targeting any of those companies.

09What to Practice This Week

Reading this page once is preparation. Running the framework out loud is practice. The two are not interchangeable. Concrete weekly practice you can do alone or with a partner:

1. Pick three questions from the question patterns section in the main guide. One from each category. Pick a classic, an infrastructure prompt, and an AI-adjacent prompt.
2. For each, run the framework end-to-end in 45 minutes. Out loud. Against a real or simulated whiteboard (Excalidraw is free and good). Time yourself with a phone alarm.
3. Record yourself. Watch the recording back the next day. Note where you spent too much time, where you hedged, where you went wide instead of deep. The first few recordings will be painful. That's the point.
4. Compare your scoping move at the start. Did you descope explicitly? Did you commit to scale numbers? Did you ask about non-functionals? If any of those was thin, redo just Step 1 a few times until it becomes muscle memory.
5. Once a week, do a mock with another engineer. Ideally one currently interviewing at your target level. The pushback signal is what you need most and what you cannot get from solo practice.

If you only have time for one of these activities, do the mock. If you only have time for one solo activity, record yourself running the framework. Reading without practice is the most common failure mode.

Reading this page once is preparation. Running the framework out loud is practice. The two are not interchangeable.

10Framework FAQ

Quick answers to questions specific to running this framework. For broader interview FAQs, see the main guide's FAQ.