System Design Interview Guide
A structured approach to answering system design questions
A system design interview tests your ability to architect scalable, maintainable software systems. It's focused on high-level problem-solving rather than code.
What should I expect?
Who is this interview usually targeted at?
Mid-level to senior engineers, tech leads, and architects.
What format is the interview?
You'll have a conversation-style session. Expect a whiteboard session. No code, no right or wrong answers.
The Interviewer's Mindset
The Real Question Interviewers Are Asking
When you're in a system design interview, the interviewer isn't just looking for a perfect solution. They're asking one fundamental question:
"Can this person think through complex problems and communicate their thought process effectively?"
This is the core of what interviewers are evaluating. They want to see how you:
- Break down complex problems
- Make trade-offs between different solutions
- Explain your reasoning clearly
- Handle feedback and adapt your approach
- Collaborate in a technical discussion
Interview Insights & Hints
✨ Be proactive. Initiate the discussion about edge cases and failures yourself. Don't wait for the interviewer to ask you about them. Demonstrating that you can identify potential issues on your own shows strong problem-solving skills and system thinking.
Remember: The interviewer is not your adversary. They want you to succeed and are looking for opportunities to help you demonstrate your skills.
The Parts of Your Answer
Requirements (5 - 10 minutes)
Functional Requirements - "What are the features?"
Start with the most important requirements and build from there.
Focus on core user-facing features and functionality that directly address the problem statement.
Non-Functional Requirements - "The Technical Requirements"
These describe how well the system should perform - the quality attributes and constraints.
✨ This is where the magic happens. If you get this part right, you know which architecture to choose. For example, if you need real-time communication, you might choose WebSockets over traditional HTTP polling.
Scalability
The ability of a system to handle increased load by adding resources.
Availability
The percentage of time a system is operational and accessible.
Performance
How quickly and efficiently a system responds to requests.
Reliability
The ability of a system to perform its functions under stated conditions.
Consistency
Whether users always see the most up-to-date data (especially in distributed systems).
Durability
Once data is written, it remains available even after failures.
Security
Protecting data and services against unauthorized access or attacks.
Maintainability
How easily the system can be updated, debugged, or enhanced.
Cost Efficiency
Designing for optimal infrastructure and operational costs (especially in cloud environments).
Assumptions (Up to 5 minutes)
State your assumptions about usage patterns, user behavior, and system characteristics. This helps clarify the problem scope and guides your design decisions.
✨ This is critical. If we know, for example, that the system is read-heavy, we can plan to optimize for reads - like using read replicas to distribute read traffic and improve performance.
Consider user behavior patterns, data characteristics, and system constraints that will influence your design decisions.
Capacity Estimation (Up to 5 minutes)
Estimate the scale of your system - traffic, storage, bandwidth.
✨ Don't waste time on exact numbers, just get a sense of the scale. Consider load (requests per second) and amount of data. You will need it for the next steps.
Traffic Estimates:
Calculate daily/monthly active users, requests per second, and peak traffic patterns.
Storage Estimates:
Estimate data size per record, growth rate, and total storage needs including replication.
Bandwidth Estimates:
Calculate incoming and outgoing data transfer rates based on traffic patterns.
High-Level Design - Components (10 minutes)
Identify the main building blocks of your system - the services, databases, and infrastructure components.
✨ Start as simple as possible - begin with a basic design that covers the functional requirements. Then, build more things based on the non-functional requirements - add load balancers for scalability, caches for performance, etc.
Services:
Identify the core application services needed to fulfill functional requirements.
Infrastructure:
Select appropriate infrastructure components like load balancers, message queues, and CDNs.
Databases:
Choose database technologies based on data models, consistency needs, and scale requirements.
Deep Dive - APIs, Data Models, Specific Choices
Get into the details: how services communicate, how data is structured, and the specific technology choices you're making.
APIs - "How services communicate"
Define REST endpoints, request/response formats, and communication protocols between services.
Data Models - "How data is structured"
Design database schemas, define relationships, and specify key data entities and their attributes.
Specific Choices - "Technology decisions and trade-offs"
Justify technology selections by explaining their benefits for your specific use case and trade-offs considered.
Edge Cases & Failure Cases
Think about unusual scenarios, boundary conditions, and unexpected situations that could break your system. Also explain how your system gracefully handles failures, recovers from errors, and maintains availability.
✨ Sometimes the design is really simple until we think of edge cases. For example, for a simple banking transaction system, we will have a very basic design of client, server, and database. But when we think of edge cases, we will understand more things to consider - like race conditions, partial success, and transaction rollbacks.
Edge Cases:
Consider unusual scenarios like network interruptions, out-of-order processing, duplicate requests, and boundary conditions.
Failure Cases:
Plan for component failures, network issues, and data inconsistencies. Discuss replication, failover, retry mechanisms, and graceful degradation.
Production Ready (At least 5 minutes before the end)
Discuss how to make your system production-ready: testing strategies, observability (monitoring, logging, tracing), deployment practices, analytics, and operational considerations.
✨ This is the place to use your experience with real systems and show ownership. It will likely help the interviewer understand your seniority level.
Testing:
Unit tests, integration tests, load testing, and chaos engineering for resilience.
Observability:
Metrics, logging, distributed tracing, and alerting for system health monitoring.
Deployment:
Blue-green/canary deployments, feature flags, migration strategies, and rollback plans.
Analytics & Operations:
User metrics, performance dashboards, cost optimization, and incident response procedures.
Ready to Practice?
Start learning the building blocks and practice with real system design questions