System Design Interviews: The 7-Step Framework You Must Follow
System Design Interviews: The 7-Step Framework You Must Follow
System design interviews evaluate how you approach ambiguous, large-scale problems — they test your thinking process more than your memorized facts. Use this seven-step framework to structure your answers, communicate clearly, and demonstrate engineering judgment in interviews.
1) Clarify requirements
Start by asking questions. Confirm functional and non-functional requirements, and identify constraints and scope.
- Functional: What features are required? (e.g., read/write throughput, search, notifications)
- Non-functional: Latency, availability, consistency, durability, cost targets
- Constraints: Time, team skill set, regulatory/compliance needs, existing systems
Sample clarifying questions:
- "What scale should this support (users, requests/sec)?"
- "Is eventual consistency acceptable or is strong consistency required?"
Why this matters: Interviewers want to see you avoid assumptions and define success criteria before designing.
2) Break the system into components
Decompose the problem into logical pieces: APIs, services, databases, caches, queues, UI, and monitoring.
- Draw a high-level block diagram
- Describe responsibilities of each component
Example components for a feed service:
- Ingest/API layer
- Processing/enrichment service
- Storage (DB for posts, metadata store)
- Cache (for hot feeds)
- Notification pipeline
Why this matters: Modularity shows you can reason about isolation, scaling, and failure domains.
3) Design for scale
Address how your system will handle load and growth.
Key techniques:
- Load balancing and horizontal scaling
- Caching (edge, CDN, in-memory caches)
- Partitioning/sharding strategies
- Asynchronous processing with queues
- Backpressure and circuit breakers
Give orders-of-magnitude estimates when possible (read/write ratios, request sizes) and explain how components scale horizontally.
4) Map the data flow
Explain how data moves through the system: ingest → process → store → serve.
- Describe request flow from client to storage and back
- Identify synchronous vs asynchronous paths
- Show where data is transformed, batched, or enriched
Include failure and retry semantics: what happens on partial failure, duplicate messages, or data loss?
5) State trade-offs and alternatives
Every design choice has trade-offs. Explicitly explain them.
Examples:
- SQL vs NoSQL: consistency and complex queries vs horizontal scale
- Cache invalidation strategies: TTL vs write-through vs event-based invalidation
- Strong consistency vs availability during partitions
Interviewers listen for awareness of operational cost, complexity, and the impact on user experience.
6) Expect follow-ups and dig deeper
Prepare to iterate based on interviewer prompts: they may ask about bottlenecks, data modeling, security, or future changes.
Common follow-ups:
- Single point of failure and mitigation
- Hot keys or uneven load distribution
- Data migration and backward compatibility
- Rate limiting and throttling
Walk through how the system evolves as requirements change (e.g., growth by 10x, adding cross-region replication).
7) Practice with real systems and mocks
Practice designing systems you've used: Twitter feed, URL shortener, chat app, file storage. Mock interviews and whiteboard sessions help you refine structure and pacing.
Practice tips:
- Timebox yourself (10–15 minutes for high-level design, then dive deeper)
- Use templates for common systems (cache patterns, DB choices)
- Get feedback on clarity and trade-off reasoning
Quick interview checklist
- Ask clarifying questions first
- Define scale and SLAs
- Draw a simple diagram and label components
- Explain data flow and failure modes
- State trade-offs and alternatives
- Anticipate and answer follow-ups
- Summarize your final design
Final tip: communicate your thought process clearly. Interviewers want to see structured reasoning, good trade-off analysis, and awareness of operational realities — not a perfect, monolithic architecture.
