# System Design Interviews: The 7-Step Framework You Must Follow # System Design Interviews: The 7-Step Framework You Must Follow System design diagram 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.