A repeatable framework for system design questions, common pitfalls, and how senior engineers structure their answers.
System design interviews are open-ended because the interviewers want to see how you think, not whether you know the "right answer". They're evaluating: (1) Do you clarify requirements before designing? (2) Can you break down a complex problem? (3) Do you know when to use which technology? (4) Can you reason about trade-offs? (5) How do you handle scale?
Use RESHADED to structure any system design answer: Requirements (functional + non-functional), Estimation (scale, QPS, storage), Storage (schema, DB choice), High-Level Design (components and connections), APIs (endpoints and contracts), Detailed Design (deep dive into 1–2 components), Evaluate (bottlenecks, trade-offs), Distinctive Features (what makes your design good).
Before drawing anything, ask: How many users? Read-heavy or write-heavy? Global or single-region? Strong consistency or eventual consistency acceptable? What's the latency requirement? These questions don't just gather info — they signal that you think like an engineer, not a coder.
Know these numbers: 1M users hitting an API 10x/day = ~115 QPS. A tweet with metadata = ~1KB. 1M tweets/day = ~1GB/day storage. A CDN cache hit reduces latency from ~150ms to ~5ms. Interviewers don't expect perfect numbers — they want to see that you can reason about scale.
URL shortener: hashing, DB design, caching, redirects. Twitter feed: fan-out, caching, real-time vs. batch. Uber/ride-sharing: geolocation, matching algorithms, real-time updates. Netflix: CDN, content delivery, recommendation systems. WhatsApp: websockets, message queues, presence detection. Each pattern maps to a category of distributed systems problems — learn the category, not just the specific question.
SQL vs. NoSQL: consistency vs. flexibility and scale. Cache vs. no cache: speed vs. staleness. Synchronous vs. asynchronous: simplicity vs. resilience. Monolith vs. microservices: simplicity vs. independent scaling. Strong consistency vs. eventual consistency: correctness vs. availability. Every design decision is a trade-off. Name them.