The system design interview framework

TL;DR

• A common HLD interview structure has 6 phases: Functional Requirements, Non-Functional Requirements, API Design, Flow Design, High-Level Architecture, and Deep Dives. The phases are sequential, but you can loop back as needed.
• Time allocation matters more than depth. The single biggest mistake is jumping to boxes on a whiteboard before clarifying what you're building and how it behaves.
• The interviewer evaluates your process, not just your architecture. A clean, structured walkthrough of a solid design beats a brilliant design delivered as a stream of consciousness.
• More senior candidates are often expected to drive the conversation: set the scope, define the APIs, trace the flows, and choose where to go deeper.
• DB design, schema choices, and indexing strategies belong in the Deep Dive phase. That's where you prove you can actually build what you drew.

Why this matters

You're 8 minutes into a "Design Instagram" interview. You've drawn four boxes on the whiteboard. The interviewer asks: "How would you handle the feed?" You realize you never clarified whether this is a chronological feed or an algorithmic one. You never asked about the scale. You backtrack, erase, redraw.

The remaining 35 minutes become a scramble. You know caching, you know sharding, you know CDNs. But you're spending mental energy reorganizing instead of designing. The interviewer's notes say: "jumped ahead, disorganized, had to be redirected."

The problem is usually not a lack of distributed-systems knowledge. It is that the candidate has not made the problem, assumptions, and decisions visible to the other person. A structure gives both sides a shared map.

For the interview, treat the time as a small design session. You are explaining a design to an engineer who does not have the context in your head, so make the scope, sequence, and decision points explicit.

Core idea: specification before architecture

The framework follows a simple dependency chain:

1. Requirements define what success means.
2. NFRs and estimates define the scale and constraints.
3. APIs and flows define what data moves and when.
4. Architecture provides components that satisfy those contracts.
5. Deep dives test the riskiest decisions and failure paths.

If a later decision cannot be tied to an earlier requirement, either the requirement is missing or the component may be unnecessary. This is a reasoning aid, not a script: adjust the order when the prompt or interviewer requires it.

The 6-Phase Framework

Here's a useful default for a system design question. The time splits assume a 45-minute interview; adjust them for the actual format and leave room for questions.

These aren't rigid walls. You'll reference NFRs during the architecture phase. You'll adjust an API during a deep dive. But the sequence should be clear to your interviewer at all times.

I recommend literally saying this at the start:

"I'll begin by nailing down functional and non-functional requirements. Then I'll sketch the key APIs and trace the critical user flows. That'll set me up for the high-level architecture, and we'll deep-dive into the most interesting parts. I'll check in with you as we go."

That sentence gives the interviewer a clear map and makes it easy to redirect the discussion.

Phase 1: Functional Requirements (3 minutes)

This phase exists for one reason: to prevent you from designing the wrong system.

Propose scope, don't ask for it

"Design Instagram" isn't one system. It's twenty. You need to narrow it down fast.

Bad: "What features should I include?" Good: "I'll focus on the core photo-sharing flow: upload, feed generation, and viewing. I'll leave stories, DMs, Reels, and search out of scope unless you'd like me to cover them."

See the difference? The first puts the burden on the interviewer. The second shows you understand the product and you're making a deliberate scoping decision. That's a staff-level signal.

List 3-5 functional requirements on the board and explicitly state what you are not building. The exclusion list prevents scope creep and makes it clear where you intend to spend the limited interview time.

What good functional requirements look like

For "Design Instagram":

• Users can upload photos with captions
• Users see a personalized feed of photos from accounts they follow
• Users can like and comment on photos
• Users can follow/unfollow other users

Out of scope: Stories, Reels, DMs, Search, Explore, Ads, Notifications

Four features. Four sentences. You've defined what you're building and what you're not. The interviewer knows exactly where this is going.

Phase 2: Non-Functional Requirements (2 minutes)

This is where most candidates are too vague. "It should be scalable and reliable" is meaningless. You need specific numbers and explicit choices.

The five NFRs that matter

State the consistency model per feature, not globally

This is a nuance most candidates miss. "The system uses eventual consistency" is too broad. Different features have different consistency needs:

• Feed: Eventually consistent (5-10 second staleness is invisible to users)
• Like counts: Eventually consistent (slight delays are acceptable)
• Follow/unfollow: Strongly consistent (unfollowing must take effect immediately)
• Photo upload: Read-your-writes consistent (user must see their own upload right away)

Stating consistency per feature shows that consistency is a spectrum, not a binary choice. It also ties the database behavior to something the user actually experiences.

Phase 3: API Design (3 minutes)

This phase is where you define the contract between the client and the system. Skip it for purely internal backend questions, but for user-facing systems (which is 80%+ of interview questions), this phase is essential.

Why API design before architecture

Most candidates go straight from requirements to boxes. The problem: without defined APIs, you don't know what data flows in, what flows out, or what operations the system needs to support. You end up designing components and then backtracking to figure out the interfaces.

Defining APIs first forces you to think about the system from the consumer's perspective. What does the client actually need? What request and response shapes do they expect?

Answering these prevents over-engineering (building components for operations nobody calls) and under-engineering (missing endpoints the client needs).

How to do it in 3 minutes

You're not writing OpenAPI specs. You're sketching 3-5 key endpoints:

POST   /photos          → Upload a photo (image, caption, user_id)
GET    /feed/{user_id}  → Get personalized feed (cursor, page_size)
POST   /likes           → Like a photo (photo_id, user_id)
POST   /follows         → Follow a user (follower_id, followee_id)
DELETE /follows         → Unfollow (follower_id, followee_id)

That's it. Five lines. The interviewer can now see: (1) what the system does from the outside, (2) you thought about pagination (cursor-based, not offset), (3) you separated read and write paths, (4) you understand REST resource modeling.

When to skip or abbreviate

• "Design the backend for X": Keep API design brief, focus on service-to-service interfaces
• "How would you scale X?": Skip API design, go straight to architecture
• "Design the data model for X": Skip API design, spend more time on schema and access patterns

For your interview: if the APIs are standard CRUD, sketch them in 60 seconds and move on. If the system has interesting API decisions (WebSocket vs. polling for real-time, GraphQL vs. REST for nested data), spend the full 3 minutes because the API choice itself becomes a talking point.

For protocol choice: default to REST for user-facing APIs, GraphQL when clients need flexible nested queries, and gRPC for internal service-to-service calls. State this in one sentence and move on.

Phase 4: Flow Design (5 minutes)

This is the phase most frameworks skip, and it's the one that prevents the worst class of design mistakes: architectures that look good on paper but don't actually work when you trace a request through them.

What flow design means

Pick 2-3 core user actions from your functional requirements and trace the complete data path:

1. User does X on the client
2. Client sends a request to Y
3. Y does Z (reads from where? writes to where? calls what?)
4. Response flows back
5. User sees the result

Worked example: Instagram photo upload

User taps "Upload" on mobile app
  → Client compresses image, sends POST /photos with image + metadata
  → API Gateway authenticates, rate-limits, routes to Upload Service
  → Upload Service stores image in S3 (object storage), gets back a URL
  → Upload Service writes photo metadata (user_id, S3 URL, caption, timestamp) to DB
  → Upload Service publishes "new_photo" event to message queue
  → Feed Service consumes event, fans out post to followers' feed caches
  → Response: 201 Created with photo_id returned to client

Worked example: Instagram feed load

User opens app, triggers GET /feed/{user_id}?cursor=X
  → API Gateway routes to Feed Service
  → Feed Service checks Redis for pre-computed feed
  → Cache HIT: return cached feed items (photo_ids + metadata)
  → Cache MISS: query Feed DB for user's timeline, hydrate with photo metadata
  → For each feed item, fetch like counts from Counters Service (or cached)
  → Response: JSON array of feed items with pagination cursor

Those two flows, written on the board in 4-5 minutes, expose which services and stores are needed, which paths are synchronous or asynchronous, and where caching belongs.

Trace the write path and the read path separately. In a non-trivial system they often have different bottlenecks, consistency needs, and scaling strategies.

Phase 5: High-Level Architecture (17 minutes)

This is the main design pass. Because the first four phases made the requirements, APIs, and flows explicit, drawing becomes assembly rather than guesswork.

The drawing sequence

Start with the user and draw left to right (or top to bottom):

1. Draw the client (mobile app, web browser, API consumer)
2. Draw the infrastructure layer (load balancer, API gateway, CDN)
3. Draw the core services (the 2-3 services that handle your functional requirements)
4. Draw the data stores (which database? cache? object storage?)
5. Draw the async paths (message queues, event buses for anything non-synchronous)
6. Label every arrow with what flows through it

Here's what a Phase 5 diagram might look like for our Instagram example:

Narrate while drawing

Don't draw silently. Every box gets a one-sentence justification:

• "I'm putting a load balancer here because we'll have multiple API servers to distribute traffic across."
• "PostgreSQL for user profiles because we have relational queries and need ACID. Feed data in Cassandra because it's write-heavy and we can tolerate eventual consistency."
• "Writes go through Kafka before hitting the feed cache because feed fanout at 50K writes/sec would overwhelm a synchronous write path."

Every component you add should be justified. If you can't explain why it's there in one sentence, you probably don't need it.

Justify with numbers, not instinct

When you add a component, connect it to your NFRs and quick estimates (see Capacity Planning for how to translate estimates into infrastructure decisions):

Phase 6: Deep Dives (15 minutes)

You've drawn the architecture. The last 15 minutes are where you prove you can actually build the system, not just draw it.

What belongs in deep dives

This is where DB design, schema choices, and scaling strategy live. The architecture gave you the "what." Deep dives give you the "how."

How to pick what to dive into

Two strategies:

1. Let the interviewer lead: "Which component would you like me to go deeper on?" Collaborative and safe.
2. Proactively dive into the hardest part: "The most interesting engineering challenge here is the feed generation pipeline. Let me walk through the database design and scaling approach." This is the staff-level move.

Offer the choice first. If the interviewer says "you pick," choose the component with the most consequential trade-offs or the clearest failure mode.

DB design in deep dives: what good looks like

When you deep-dive on a database design, cover these four things:

1. Schema (30 seconds):

CREATE TABLE photos (
  photo_id    BIGINT PRIMARY KEY,  -- Snowflake ID for sortability
  user_id     BIGINT NOT NULL,
  s3_url      TEXT NOT NULL,
  caption     TEXT,
  created_at  TIMESTAMP DEFAULT NOW()
);
-- PostgreSQL: create index separately
CREATE INDEX idx_user_created ON photos (user_id, created_at DESC);

2. Access patterns (30 seconds): "The primary read pattern is: get all photos by user_id, ordered by created_at descending. That's a range scan on the composite index. Secondary: get photo by photo_id (primary key lookup, O(1))."

3. Why this schema (30 seconds): "I chose a composite index on (user_id, created_at) because that's our hot query path. Putting created_at in descending order means the most recent photos are physically co-located on disk, which makes the range scan fast."

4. What changes at scale (30 seconds): "At 1B photos, this table is ~5TB. We'd partition by user_id range or hash. The index stays effective because all queries include user_id."

That's a complete DB deep dive in 2 minutes. Specific, justified, and scale-aware.

The depth expected at each level

Adapting the Framework

For 30-minute interviews

Compress Phases 1-4 into 5 minutes total. State requirements and APIs as assertions rather than discussions. Spend 12 minutes on architecture, 13 on deep dives.

For 60-minute interviews

Use the extra time for a second deep dive and more detailed API/flow design. Add a "Bottlenecks & Evolution" section: "Here's what breaks first as we grow from 10M to 100M users, and here's the migration path."

For different question types

How This Shows Up in Interviews

For the 15 most common ways candidates fail this framework, see Common Pitfalls.

The signals interviewers look for

At more senior levels, interviewers often look for three meta-skills:

1. Ownership of the conversation: Do you drive, or do you wait to be told what to do?
2. Trade-off articulation: Can you name the alternatives and explain why you chose this one?
3. Scope management: Can you decide what's important and what to skip?

The framework gives you all three. You drive by announcing the phases. You articulate trade-offs at every decision point. You manage scope in Phase 1 by explicitly setting boundaries.

Common interviewer follow-ups

30-second answer

"I use a six-phase sequence: clarify functional requirements, set measurable NFRs, sketch the key APIs, trace the main read and write flows, draw the architecture, and then deep-dive on the riskiest decisions. The order keeps the design tied to the problem and leaves time to discuss scale and failure modes."

5-minute explanation

Start by proposing a narrow scope and an explicit out-of-scope list. State only the NFRs that will change the design, and label numbers as assumptions when the prompt does not provide them. Sketch a few operations, trace one read and one write path, then draw the simplest architecture that satisfies those contracts. Finish by checking the most important schema, scaling, consistency, and failure decisions. This is a framework for communicating reasoning; it is not a requirement to mention every component.

Quick Recap

1. The 6-phase framework (Functional Requirements → Non-Functional Requirements → API Design → Flow Design → High-Level Architecture → Deep Dives) gives you a structured path through any system design interview.
2. Phases 1-4 together form a complete specification. Spending 13 minutes here prevents the "redraw at minute 20" disaster that sinks most interviews.
3. API design forces you to think from the consumer's perspective, catching missing requirements like idempotency, pagination, and real-time vs. polling.
4. Flow design catches async gaps, race conditions, and write/read path mismatches before you commit to architecture.
5. DB design, schema choices, and indexing strategies belong in Deep Dives, where you prove you can build what you drew.
6. The single highest-signal behavior: announcing your structure at the start, checking in after each phase, and adapting when the interviewer steers.

Related Concepts

• Estimation: The skill of rapid back-of-envelope math. Use estimation inside Phases 2 and 5 to justify component choices with numbers instead of instinct.
• Capacity Planning: Translating estimates into concrete infrastructure decisions. Essential for Phase 5 when deciding how many servers, what cache size, and when to shard.
• Common Pitfalls: A pre-flight checklist of the 15 mistakes that fail interviews. Review this the night before every interview to internalize the anti-patterns.