System Design Notes / Framework

The 6-Step Interview Framework

A structured approach for Staff-level system design interviews. Every design on this site follows these six steps — in order, with time discipline. Read this first.

~45 min interview Adapted from RESHADED Staff / FAANG level
How the framework fits together
Interview flow — 45 minutes
01 Requirements ~5 min 02 Estimation ~5 min 03 API Design ~5 min 04 Data Model ~5 min 05 High-Level ~10 min 06 Deep Dive & Tradeoffs ~15 min · interviewer-guided revise if needed Scope Size Contract Schema Architecture Foundation (~20 min) — do these well before drawing boxes
Time allocation across 45 minutes
Req
Est
API
Data
High-Level Design
Deep Dive & Tradeoffs
Requirements (5m)
Estimation (5m)
API Design (5m)
Data Model (5m)
High-Level Design (10m)
Deep Dive (15m)
The core principle

The first four steps are foundation work — they exist so that your High-Level Design is grounded in real constraints, not wishful thinking. Most candidates rush to step 5. The ones who spend the first 20 minutes well draw better diagrams and defend them better in step 6.

01
Step One
Requirements Clarification
Scope the problem before touching the whiteboard
⏱ ~5 min

The most common mistake in design interviews is jumping to solutions. Interviewers deliberately leave the problem ambiguous — your first job is to compress that ambiguity into an agreed-upon scope, without asking so many questions you appear lost.

Functional vs Non-Functional — what to ask
FUNCTIONAL ▸ What can users do? ▸ What is explicitly out of scope? ▸ What does success look like? ▸ Real-time or eventual updates? ▸ Read-heavy or write-heavy? ▸ Any hard consistency needs? NON-FUNCTIONAL ▸ Scale: DAU, RPS, data volume ▸ Latency SLA (p99 target?) ▸ Availability (99.9% vs 99.99%) ▸ Consistency model ▸ Durability requirements ▸ Security / compliance needs
Functional Requirements
  • Core user actions: What does the user actually do? Create, read, search, stream, delete?
  • Carve out scope explicitly: "For this interview I'll focus on X and Y, not Z." Name what's out of scope — don't let it haunt later steps.
  • Clarify the happy path: What does success look like for the primary use case?
  • Edge cases up front: Real-time vs. eventual? Read-heavy or write-heavy? Hard consistency requirements?
Non-Functional Requirements
  • Scale targets: Users, RPS, data volume — get an order of magnitude, not exactness.
  • Latency SLAs: Is p99 < 100ms a hard requirement or a nice-to-have?
  • Availability target: 99.9% vs 99.99% changes the design significantly — single-region vs multi-region.
  • Consistency model: Strong vs. eventual — especially critical for distributed state.
  • Durability: What's the cost of data loss? Financial records vs. social media drafts are very different.
Interview Signal

Explicitly labeling the FR/NFR split shows Staff-level systems thinking — most candidates conflate them. End step 1 with a verbal confirm: "So to confirm scope: users can do X, the system must handle Y scale, and strong consistency isn't required. Sound right?" This demonstrates structured thinking and gives the interviewer a checkpoint.

02
Step Two
Capacity Estimation
Order-of-magnitude thinking, not precision arithmetic
⏱ ~5 min

Estimation isn't a math test — it's a reasoning signal. The interviewer wants to see that you can derive architecture constraints from numbers. A system at 1K RPS and one at 1M RPS need fundamentally different designs. Get the numbers on the board early so every decision that follows is grounded.

Estimation chain — how numbers connect to decisions
Users / DAU starting point Read / Write RPS per type Storage per record × volume Bandwidth inbound / outbound Architecture decisions ↓ Numbers drive: # servers · cache size · DB sharding · CDN vs origin split
Traffic
  • Daily Active Users (DAU)
  • Read RPS vs Write RPS
  • Read:Write ratio
  • Peak traffic multiplier (2–3×)
Storage
  • Bytes per record
  • Records created per day
  • Retention / TTL policy
  • 5-year total storage
Network
  • Bandwidth per request
  • Inbound vs outbound
  • CDN vs origin split
Cache
  • % reads served from cache
  • Cache memory needed
  • Eviction pressure
Useful constants to memorize

1M req/day ≈ 12 RPS.   1B req/day ≈ 12K RPS.
Char = 1 byte  ·  Int = 4 bytes  ·  UUID = 16 bytes  ·  Timestamp = 8 bytes
1TB = 10¹² bytes. Round aggressively — precision is noise.

Interview Signal

Don't just produce numbers — narrate your reasoning: "I'm assuming 10% of users are active daily, that gives us…" The interviewer is scoring your reasoning process, not your arithmetic accuracy. Sanity-check final numbers out loud before moving on.

03
Step Three
System Interface Design
Define the contract before the implementation
⏱ ~5 min

Define the API before drawing boxes. This forces you to think from the consumer's perspective, surfaces ambiguities missed in step 1, and creates a stable contract that anchors the rest of the design. You're not writing production code — sketch the signature, key parameters, and response shape.

What a well-defined API endpoint covers
POST /resource endpoint definition HTTP method GET POST PUT DELETE Request params path · query · body Auth / Identity JWT · API key · session Response shape { id, status, data } Error codes 4xx · 5xx · rate limit Pagination cursor · offset · stream
  • API style: REST, gRPC, GraphQL, WebSocket — pick the right tool and justify it briefly.
  • Core endpoints: One per major functional requirement. Name, method, key params, response shape.
  • Auth/Identity: Where does user identity come from? API key, JWT, session token?
  • Error contract: What does failure look like? Rate limits, not-found, auth failure.
  • Pagination / streaming: How does the client consume large result sets?
Interview Signal

This step reveals whether you think product-first or infrastructure-first. Strong candidates define the interface the way a platform engineer would — they think about what changes independently: client contract vs. internal routing vs. storage layer. Weak candidates skip this and start drawing load balancers without knowing what the system actually does.

04
Step Four
Data Model
Schema, storage type, and access patterns
⏱ ~5 min

Most design flaws trace back to a mismatched data model. Define your entities, their relationships, and — critically — your read/write access patterns before choosing a storage technology. Storage choice should follow access pattern, not the other way around.

Storage decision tree — start with access patterns
What's your primary access pattern? Key lookup Complex joins Full-text / range Key-Value / NoSQL Redis · DynamoDB · Cassandra Relational SQL Postgres · MySQL · Aurora Search / Time-Series Elasticsearch · InfluxDB High write throughput Flexible schema Horizontal sharding ACID transactions Relational integrity Complex queries Text search / ranking Time-series queries Analytics aggregations
  • Core entities: What are the 3–5 primary data objects? Sketch their key fields.
  • Relationships: One-to-many, many-to-many — does this need foreign keys or denormalization?
  • Access patterns: Read by ID? Range scans? Full-text search? This drives the storage choice.
  • SQL vs NoSQL: Don't default — justify. ACID needs? SQL. Flexible schema + scale? NoSQL.
  • Indexes: What are your hot query patterns? Which fields need indexing?
  • Partitioning key: For distributed storage — what's your shard key and why?
Interview Signal

Picking a storage type without mentioning access patterns is a yellow flag. The best candidates say: "My primary read pattern is lookup by short code, O(1) — this maps naturally to a key-value store." The choice follows the reasoning, not the other way around.

05
Step Five
High-Level Design
Draw the system end-to-end before going deep
⏱ ~10 min

This is where you put boxes on the board — but only after the four steps above have grounded you. Your goal is a working end-to-end sketch that satisfies the core functional requirements at the estimated scale. Resist the urge to go deep on any single component here.

Generic high-level architecture — standard building blocks
Client Web / Mobile CDN static assets Load Balancer L7 · round robin App Servers stateless auto-scaling multiple instances Cache Redis / Memcached Primary DB SQL / NoSQL Read Replica ×N instances Msg Queue Kafka / SQS Workers async processing route read write miss DRAW BOTH PATHS Write path: Client → LB → App → DB Read path: Client → LB → App → Cache → DB
  • Client layer: Web, mobile, SDK — what initiates requests?
  • DNS + CDN: Where does traffic enter? Static assets vs. dynamic routing?
  • Load balancer: L4 vs L7, routing strategy, sticky sessions needed?
  • Application servers: Stateless + auto-scaling. How many at peak RPS?
  • Cache layer: Read-through, write-through, or aside? Redis vs Memcached?
  • Primary datastore: Your choice from step 4, with replicas called out.
  • Message queue: Do any operations need to be async? Kafka, SQS, Pub/Sub?
Drawing Discipline

Label every arrow with the protocol or data being passed. Show data flow for both the write path and the read path — they're often different. If you have a cache, explicitly show cache hit vs. cache miss flow. An unlabeled diagram is an unclear design.

Interview Signal

At Staff level, proactively call out the bottleneck in your own design before they ask: "The datastore is the bottleneck at this write rate — I'll address that in the deep dive." This shows architectural ownership, not just pattern recognition.

06
Step Six
Deep Dive & Tradeoffs
Own the hard problems — don't hide from them
⏱ ~15 min

This is where Staff-level candidates separate themselves. You've drawn a working system — now you and the interviewer go deep on the hardest parts. The best candidates proactively steer this conversation toward the most interesting tradeoffs, rather than waiting to be asked.

How to prioritize deep dive areas
Your bottleneck called out in step 5 → start here always Pick 2–3 areas go deep on each depth beats breadth name tradeoffs explicitly Reserve ~10 min for interviewer questions best signal is here Common deep dive areas → Scalability Failure modes Consistency Hot spots ID generation Security Observability
  • Scalability bottlenecks: Where does the system break under 10× load? What's the mitigation?
  • Failure modes: What happens when a DB replica lags? A cache is cold? A service goes down?
  • Consistency tradeoffs: Where did you accept eventual consistency? What's the user-visible impact?
  • Hot spots / thundering herd: What if one resource gets 100× normal traffic?
  • ID generation: UUID vs auto-increment vs Snowflake — why does it matter here?
  • Security: Auth, rate limiting, input validation — where are the attack surfaces?
  • Monitoring & observability: What metrics matter? How do you know the system is healthy?
Interview Signal

The mark of a Staff-level engineer in this step is intellectual honesty about the tradeoffs in their own design. Saying "this design has a write bottleneck at the DB layer — here are three ways to address it and why I'd start with read replicas" is far stronger than pretending the design is perfect. Interviewers probe for exactly this.