Interview Prep
System Design Interview Framework
The system design interview tests your ability to design complex distributed systems under time pressure. Success requires a structured approach that demonstrates breadth of knowledge and depth in key areas.
- Structure — Follow a repeatable framework for every problem
- Communication — Articulate trade-offs clearly and confidently
- Iteration — Refine your design based on feedback and constraints
The framework is your compass—adapt it to the terrain, but never lose direction.
The Five-Phase Framework
A successful system design interview follows five distinct phases. Each phase builds on the previous, creating a coherent narrative from requirements to detailed design.
DfSystem Design Interview
A system design interview is a collaborative exercise where you design a large-scale system while communicating your thought process, trade-offs, and technical decisions to an interviewer. The goal is not to arrive at a single "correct" answer, but to demonstrate structured thinking, technical breadth, and the ability to make informed decisions under uncertainty.
Phase 1: Requirements Clarification (5-8 minutes)
Before designing anything, understand what you're building. Ask questions across four dimensions:
| Dimension | Key Questions |
|---|---|
| Functional | What are the core use cases? Who are the users? What actions can they take? |
| Non-Functional | What are the latency, throughput, and availability requirements? |
| Scale | How many users? How much data? What is the expected growth rate? |
| Constraints | What is the timeline? Budget? Team size? Existing infrastructure? |
Never skip requirements gathering. Interviewers intentionally leave the problem vague to see if you proactively seek clarity. Candidates who jump straight to design often miss critical constraints that invalidate their solution.
Phase 2: Estimation and Scoping (3-5 minutes)
Quantify the problem to ground your design in reality:
Capacity Estimation
Here,
- =Queries per second
- =Average record size in bytes
- =Data retention period in seconds
Estimating Storage for a Photo Sharing App
Suppose 100M daily active users upload 3 photos per day, each 2MB:
Daily uploads: 100M × 3 = 300M photos/day Daily storage: 300M × 2MB = 600TB/day Annual storage: 600TB × 365 ≈ 219PB/year
With 3x replication: 219PB × 3 = 657PB/year
This tells you that a single database is not feasible—sharding and distributed storage are mandatory.
Phase 3: High-Level Design (10-15 minutes)
Sketch the major components and their interactions. Focus on the data flow from client to storage.
Key Design Decisions at This Stage
- Synchronous vs Asynchronous: Which operations need immediate responses?
- Database choice: SQL, NoSQL, or hybrid?
- Caching: What data should be cached and where?
- Communication: REST, gRPC, or message queues?
Phase 4: Deep Dive (15-20 minutes)
The interviewer will ask you to go deeper on specific components. This is where you demonstrate technical depth.
DfDeep Dive
A deep dive focuses on the most challenging or critical component of your design. It typically involves data modeling, API design, algorithm selection, or addressing specific non-functional requirements like consistency or fault tolerance.
Common Deep Dive Topics
- Data Model Design: Schema design, indexing strategy, partitioning key
- Consistency Model: Strong vs eventual consistency, conflict resolution
- Fault Tolerance: Replication, failover, disaster recovery
- Performance Optimization: Caching layers, read replicas, connection pooling
Phase 5: Trade-offs and Wrap-up (3-5 minutes)
Summarize your design, acknowledge limitations, and discuss trade-offs:
Every design decision has trade-offs. The best candidates proactively acknowledge what they sacrificed and why. This demonstrates intellectual honesty and senior-level thinking. A candidate who claims their design has no downsides is a red flag.
The Communication Framework
Effective communication is as important as technical correctness:
The STAR Method for System Design
| Step | Description | Example |
|---|---|---|
| Situation | Restate the problem and constraints | "We need to design a URL shortener for 100M URLs/day" |
| Task | Identify the key challenges | "The main challenges are high read throughput and low latency" |
| Action | Present your solution | "I'll use a hash-based approach with a 7-character base62 encoding" |
| Result | Discuss trade-offs and alternatives | "This gives O(1) lookup but requires collision handling" |
Handling Pushback
When the interviewer challenges your design:
- Listen carefully — Understand the concern fully
- Acknowledge the trade-off — Don't be defensive
- Propose alternatives — Show flexibility
- Make a decision — Don't waffle indefinitely
Decision Quality
Here,
- =Decision quality score
- =Technical correctness of the solution
- =Clarity and structure of explanation
- =Time taken to reach the decision
Common Mistakes to Avoid
- Jumping to solutions without understanding requirements
- Over-engineering — adding unnecessary complexity
- Ignoring scale — designing for 100 users when the problem says 100M
- Single points of failure — missing redundancy in critical paths
- Silent design — thinking without communicating
Practice the framework with 3-5 different problems before your interview. The goal is to make the structure automatic so you can focus on the content, not the process.
Practice Exercises
-
Framework Application: Using the five-phase framework, design a system like Twitter's tweet feed. Walk through each phase, spending appropriate time on each.
-
Time Management: Time yourself designing a chat application. Allocate 5 minutes for requirements, 3 for estimation, 12 for high-level design, 15 for deep dive, and 5 for trade-offs.
-
Communication Practice: Explain your design of a rate limiter to a non-technical friend. Identify where they get confused and refine your explanation.
-
Trade-off Analysis: For a URL shortener, list at least 5 trade-offs between different design approaches (hash-based, counter-based, pre-generated).
Key Takeaways:
- Follow the five-phase framework: Requirements, Estimation, High-Level Design, Deep Dive, Trade-offs
- Communication is as important as technical correctness
- Proactively acknowledge trade-offs and limitations
- Practice the framework until the structure is automatic
- Never skip requirements gathering—it sets the direction for everything
What to Learn Next
-> Requirements Gathering Deep dive into eliciting and categorizing system requirements.
-> Estimation Techniques Master back-of-the-envelope calculations for capacity planning.
-> High-Level Design Techniques for sketching system architecture quickly and clearly.
-> Deep Dive Design Methods for diving deep into critical system components.
-> Scalability Fundamentals Vertical vs horizontal scaling, load balancing, and capacity planning.
-> CAP Theorem Consistency models, availability, and partition tolerance.