---
model: claude-opus-4-1
allowed-tools: Task, Read, Bash, Grep, Glob, Write
argument-hint: <system-name> [--depth=standard|deep] [--focus=architecture|scalability|trade-offs] [--generate-diagram=true|false]
description: Design complete systems with WHY, WHAT, HOW, CONSIDERATIONS, and DEEP-DIVE framework
---

# System Design Interview Coach

Complete framework for designing systems from problem to implementation. Includes WHY/WHAT/HOW structure, trade-off analysis, mermaid diagrams, and deep-dive optimizations.

## Interview Flow (60 minutes)

### Phase 1: Requirements & Context (5 minutes)
**Your goal**: Understand the problem deeply before designing

Ask clarifying questions:
- Scale: users, requests per second, data volume?
- Availability: SLA requirements (99.9%, 99.99%)?
- Latency: response time targets?
- Consistency: strong or eventual?
- Features: read-heavy, write-heavy, or balanced?
- Growth: expected growth rate?

**Interviewer's watching**:
- Do you ask the right questions?
- Do you understand the constraints?
- Can you estimate numbers?

### Phase 2: High-Level Architecture (10 minutes)
**Your goal**: Outline the system at 30,000 feet

Cover:
- Major components (load balancer, services, databases, caches)
- Communication patterns (sync/async, protocols)
- Data flow from user request to response
- Rough scalability approach

Draw simple diagram showing component interactions.

**Interviewer's watching**:
- Do you think in systems?
- Can you structure complexity?
- Do you know when to keep it simple?

### Phase 3: Detailed Component Design (20 minutes)
**Your goal**: Explain key components with confidence

Pick 2-3 components to discuss:
- How does this component work?
- Why this technology choice?
- What are the constraints it handles?
- How does it scale?

**Interviewer's watching**:
- Do you have technical depth?
- Can you justify decisions?
- Do you know trade-offs?

### Phase 4: Scalability & Trade-Offs (15 minutes)
**Your goal**: Show senior-level thinking

Discuss:
- Bottlenecks: What breaks first at 10x growth?
- Consistency: Strong vs eventual? Why?
- Reliability: Failure modes and recovery?
- Cost: What drives operational expense?
- Complexity: Is this operationally feasible?

**Interviewer's watching**:
- Do you think like a Staff engineer?
- Can you make principled trade-offs?
- Do you understand operational reality?

### Phase 5: Extensions & Deep-Dives (8 minutes)
**Your goal**: Demonstrate mastery

Address follow-up questions:
- "How would you handle [new requirement]?"
- "What's the hardest part of operating this?"
- "What would you optimize for [metric]?"
- "How would you debug this in production?"

**Interviewer's watching**:
- Are you thinking ahead?
- Can you handle surprises?
- Do you know what you don't know?

## System Design Framework

### WHY: Problem & Context
**What to cover**:
- Problem statement (1-2 sentences)
- Primary use cases (top 3-5)
- User base and growth expectations
- Non-functional requirements (scale, latency, availability)
- Business context (why does this matter?)

**For interviewer's benefit**:
- Shows you understand the problem before solving it
- Demonstrates customer empathy
- Proves you can estimate and scope

### WHAT: Components & Data Model
**What to cover**:
- Core entities (Users, Posts, Comments, etc.)
- Entity relationships
- Storage requirements (how much data?)
- Major services (Authentication, Feed, Search, etc.)
- API contracts (what endpoints do we need?)

**For interviewer's benefit**:
- Shows you think about data structure
- Demonstrates you can decompose systems
- Proves you understand component boundaries

### HOW: Architecture & Patterns
**What to cover**:
- Request flow (from user → response)
- Service architecture (monolith vs microservices decision)
- Communication patterns (synchronous, asynchronous, pub-sub)
- Storage topology (where does data live?)
- Caching strategy (where, what, how long?)
- Replication and failover

**For interviewer's benefit**:
- Shows you know architectural patterns
- Demonstrates systems thinking
- Proves you can make principled decisions

### CONSIDERATIONS: Trade-Offs & Reality
**What to analyze**:

**Consistency**
- Strong: Always get latest data (high latency, low availability)
- Eventual: Might get stale data (low latency, high availability)
- Your choice: "For [reason], we accept [consistency model]"

**Scalability**
- Vertical: Big machines (simpler, limited)
- Horizontal: More machines (complex, unlimited)
- Your choice: "We scale [direction] because [reason]"

**Reliability**
- Single point of failure? (bad)
- Replication strategy? (multiple copies)
- Disaster recovery? (backup and restore procedure)
- Your choice: "We replicate [this way] to handle [failure]"

**Cost**
- Storage: What's the cost per GB?
- Compute: What's the cost of this many servers?
- Bandwidth: What's the egress cost?
- Your choice: "This costs [X] but solves [Y]"

**Operational Complexity**
- How many different technologies?
- How hard is debugging?
- What's the on-call pain?
- Your choice: "We keep it simple: [reason]"

### DEEP-DIVE: Component Optimization
**For each major component**, be prepared to discuss:

1. **Bottleneck Analysis**
   - What's the scaling limit?
   - Where would we hit the wall first?
   - How do we know?

2. **Optimization Opportunities**
   - What could we do to handle more load?
   - What are the trade-offs?
   - When is this optimization worth doing?

3. **Failure Modes**
   - What if [component] fails?
   - How do we detect it?
   - How do we recover?

4. **Operational Concerns**
   - How do we monitor this?
   - What metrics matter?
   - How do we debug issues?

5. **Alternative Approaches**
   - What's another way to design this?
   - When would you choose it?
   - What problems does it have?

## Mermaid Diagram Strategy

Create diagrams that show:
1. **Architecture Diagram**: Components and communication
2. **Data Flow**: Request path through the system
3. **Database Schema**: Key entities and relationships

**Tips**:
- Keep diagrams simple initially
- Add detail when asked
- Label important decisions
- Annotate bottlenecks

## Example: Design Facebook Feed

### WHY
- **Problem**: Show users their friends' posts in a personalized, real-time feed
- **Use Cases**:
  1. User opens app → see recent posts from friends
  2. Friend posts → appears in followers' feeds quickly
  3. Massive scale: billions of posts, minutes of latency acceptable
- **Requirements**:
  - Read-heavy (100:1 read to write ratio)
  - Latency: Feed load < 200ms
  - Availability: 99.99%
  - Consistency: Eventual OK (a few minutes lag acceptable)

### WHAT
- **Entities**: User, Post, Friendship, Like, Comment
- **Relationships**: User → Post (1:many), User → Friend (many:many)
- **Storage**: Posts: 100s of billions, User data: billions
- **Services**: Auth, Post Creation, Feed Service, Search
- **APIs**:
  - POST /posts (create)
  - GET /feed (get user's feed)
  - POST /posts/{id}/like (like post)

### HOW
- Load balancers distribute requests
- Stateless web servers handle auth and routing
- Post service writes posts to database
- Feed service reads from cache first, database second
- Cache layer (Redis) stores hot posts
- Fanout on write: When user posts, push to all followers' feeds
- Asynchronous: Queue for fanout, workers process

### CONSIDERATIONS
- **Consistency**: Eventual consistency (a few second lag OK)
- **Scalability**: Horizontal—more servers as needed
- **Reliability**: Multi-region replication for availability
- **Cost**: Balance storage vs computation
- **Complexity**: Fanout-on-write is complex but enables fast reads

### DEEP-DIVE
1. **Fanout Bottleneck**: Celebrity posts with 100M followers?
   - Solution: Hybrid fanout—fanout for normal users, cache for celebrities
2. **Feed Personalization**: How do we rank posts?
   - Solution: ML model, but start with recency + engagement
3. **Real-time Updates**: How do we push new posts?
   - Solution: Long-polling, WebSockets, or event stream

## Talking Points During Interview

**When introducing your design**:
- "Let me outline the system at a high level..."
- "The key insight here is [insight]"
- "This design makes [requirement] easy"

**When defending a choice**:
- "We chose [option] because [constraint] → [option] is better"
- "The trade-off is [cost] for [benefit]"
- "This would change if [different constraint]"

**When asked about scaling**:
- "Currently [component] is the bottleneck"
- "We'd scale [direction] because [reason]"
- "This approach works until [limit], then we'd [next evolution]"

**When asked about failure**:
- "If [component] fails, [other component] takes over"
- "We'd detect it via [monitoring], then [recovery action]"
- "This is why we replicate [data/component]"

## Red Flags to Avoid

❌ Diving into implementation details too early
❌ Not asking clarifying questions
❌ Designing for scale you don't need
❌ Making technology choices without justification
❌ Ignoring operational reality
❌ Treating consistency/availability as separate concerns
❌ Not discussing trade-offs

✓ Start broad, add detail on request
✓ Ask clarifying questions upfront
✓ Design for the specified scale
✓ Justify technology choices
✓ Consider how humans operate it
✓ Explicitly discuss trade-offs
✓ Show you understand what you don't know

## Success Criteria

You're ready when you can:
- ✓ Clarify ambiguous requirements with good questions
- ✓ Outline architecture clearly on a whiteboard
- ✓ Explain each component's role
- ✓ Justify your technology choices
- ✓ Discuss trade-offs explicitly
- ✓ Handle "what if" questions with confidence
- ✓ Show understanding of operational reality
- ✓ Demonstrate Staff+ systems thinking