System Design Interview Framework

📋 Overview

A system design interview is a collaborative problem-solving session that tests your ability to build large-scale, distributed systems. It is deliberately ambiguous to see how you gather requirements, handle trade-offs, and navigate technical complexity. Success is measured not just by the final architecture, but by your communication, structured thinking, and depth of technical knowledge.

---

🏗️ Core Principles & Characteristics (The 4-Step Approach)

1. Step 1: Understand & Scope (5-10m):
   • Ask clarifying questions: Who is the user? What is the scale (DAU/MAU)?
   • Define Functional (Features) vs. Non-Functional (Latency, Availability, Consistency) requirements.
2. Step 2: High-Level Design (10-15m):
   • Sketch the "Blueprint": Load Balancer -> Web Servers -> DB -> Cache.
   • Do a "Back-of-the-envelope" estimation for storage and QPS.
3. Step 3: Deep Dive (15-20m):
   • Focus on the most challenging components (e.g., sharding strategy, data consistency).
   • Define the Data Schema and API endpoints.
4. Step 4: Wrap Up (5m):
   • Identify bottlenecks and failure points.
   • Suggest future improvements (Monitoring, Disaster Recovery).

---

⚖️ Trade-offs: Pros & Cons

• The "Goldilocks" Design:
  • Pros: Shows you understand that there is no "perfect" system.
  • Cons: Spending too much time on trade-offs can prevent you from finishing the high-level diagram.
• Breadth vs. Depth:
  • Pros: Mentioning many technologies (Redis, Kafka, S3) shows breadth.
  • Cons: You must be prepared to go deep into any technology you mention.

---

🌍 Real-World Implementation

• Requirements for "Design Twitter":
  • Functional: Post tweet, Timeline, Follow.
  • Non-functional: High availability (eventual consistency is okay for timelines), low latency for reads.
• Scale: 300M DAU, 500M tweets/day.
• Key Challenge: Fan-out (how to push a tweet from a celebrity to 100M followers).

---

💡 Interview "Gotchas" & Tips

• Don't ignore the numbers: If the interviewer gives you a scale, use it. Calculating 100GB vs 100TB changes your database choice.
• SPOF Identification: Always check if your design has a single point of failure (e.g., a single master database).
• The "Silent" Interviewer: If they stop talking, ask: "Does this part of the design make sense, or should I go deeper into the database sharding?"

---

📐 Suggested Architecture Primitives

• Load Balancer: For entry-point scaling.
• Distributed Cache: For hot-data offloading.
• Message Queue: For asynchronous decoupling.
• Object Storage: For static/media assets.
• Relational vs. NoSQL: Choosing based on data structure and consistency needs.