The System Design Interview Framework

A four-step structure that keeps every answer clear, scoped and interview-ready from the first minute.

FresherTheory12 min read

The four-step framework

StreamHub production architecture (AWS)

End-to-end path from user to data — reference this when placing any new service.

Every strong answer follows the same rhythm: understand the problem before solving it, sketch before optimising, and name trade-offs before the interviewer has to ask.

1. Scoperequirements + scale

2. High-level designboxes + APIs + estimates

3. Deep divedata model + bottlenecks

4. Wrap uptrade-offs + ops

Spend roughly 3–5 min on scope, 10–15 on HLD, 10–20 on deep dive, 3–5 on wrap-up.

The four steps

Clarify requirements — functional (what users do) and non-functional (scale, latency, availability).
High-level design — boxes and arrows: clients, APIs, data stores, async paths.
Deep dive — pick two or three components the interviewer cares about and go deep.
Wrap up — bottlenecks, failure modes, monitoring, and what you would build next.

Spend the first five to eight minutes on steps 1 and 2. Jumping straight to Redis or Kafka without scoping the problem is the fastest way to lose the interviewer's confidence.

Step 1: Clarify requirements

Start by asking questions. Interviewers expect it — vague prompts are intentional.

Questions to ask early

Who are the users and what is the core user journey?
What is the read/write ratio? Peak QPS? Expected data volume in five years?
Latency target — p99 under 200 ms or "best effort"?
Consistency requirements — can a user see stale data for a few seconds?
Geographic distribution — single region or global?
Out of scope — payments, admin panel, analytics pipeline?

Write assumptions on the whiteboard (or shared doc). Say them aloud: "I'll assume 10 million DAU, mostly reads, and strong consistency is not required for the feed."

Java

Functional:     Users upload videos, follow creators, watch a personalised feed
Non-functional: 50M DAU, 100:1 read/write, p99 < 300ms, 99.9% availability
Out of scope:   Live streaming, payments, content moderation ML

Step 2: High-level design

Draw a simple diagram: client → load balancer → app servers → database/cache/queue. Label data flows for the two or three most important operations.

For most product designs, a three-tier pattern (presentation, application, data) is enough at this stage. Add CDN, cache, or message queue only when a requirement forces it.

Step 3: Deep dive

The interviewer will steer you toward specific areas: "How would you shard the database?" or "What happens when the cache goes down?" Pick components you understand well and connect them to the requirements you stated earlier.

Common deep-dive topics

Data model — entities, primary keys, indexes, hot partitions.
API design — key endpoints, pagination, idempotency for writes.
Scaling — horizontal app tier, read replicas, caching layer.
Reliability — retries, circuit breakers, graceful degradation.
Consistency — eventual vs strong, conflict resolution.

Step 4: Wrap up and trade-offs

End with honesty: every design has weaknesses. Name yours proactively.

Java

# Example monitoring signals you'd mention
metrics:
  - api.request.duration.p99
  - db.replica.lag.seconds
  - cache.hit_ratio
alerts:
  - p99_latency > 500ms for 5min
  - replica_lag > 30s

Aspect	What impresses	What hurts
Opening	Asks clarifying questions	Jumps to microservices immediately
Diagram	Clear boxes, labelled flows	Unreadable spider web
Depth	Explains why, not just what	Lists buzzwords without context
Time	Leaves 5 min for questions	Runs over without summarising

Opening
What impressesAsks clarifying questions
What hurtsJumps to microservices immediately
Diagram
What impressesClear boxes, labelled flows
What hurtsUnreadable spider web
Depth
What impressesExplains why, not just what
What hurtsLists buzzwords without context
Time
What impressesLeaves 5 min for questions
What hurtsRuns over without summarising

Interviewers score process and communication as much as technical depth.

Time management

Phase	Minutes	Goal
Requirements	5–8	Assumptions written, scope agreed
High-level design	10–12	Diagram with main components
Deep dive	15–20	2–3 components in detail
Wrap-up	3–5	Bottlenecks, monitoring, next steps

Requirements
Minutes5–8
GoalAssumptions written, scope agreed
High-level design
Minutes10–12
GoalDiagram with main components
Deep dive
Minutes15–20
Goal2–3 components in detail
Wrap-up
Minutes3–5
GoalBottlenecks, monitoring, next steps

A 45-minute session leaves little room for tangents. If you are stuck, say what you would research offline and move on — that is better than silence.

Quick recall

Everything you need if you only revisit this box.

Four steps: clarify → high-level design → deep dive → wrap-up with trade-offs.
Spend the first third on requirements; never design before you understand the problem.
Draw a simple three-tier diagram before adding caches, queues, or shards.
Deep-dive on components the interviewer points to, tied back to your stated NFRs.
Proactively name weaknesses and monitoring — it signals production thinking.
Ask questions early; interviewers reward structured curiosity over instant answers.

Test yourself

Answer these before moving on — recall is what makes it stick.