System Design Speaking

Why B is the model estimation: structured, narrated, order-of-magnitude

Back-of-envelope estimation is a key skill in system design interviews. The format:

1. State assumptions explicitly: "2 photos per week per user" — reasonable, defensible
2. Calculate step by step: "200M × 500KB = 100TB per week" — show your math
3. Extrapolate: weekly → annual
4. Account for derived data: thumbnails — shows you think about real systems
5. Give a range: "rough order of magnitude" — you're estimating, not being precise

Estimation vocabulary:

• "Let me do a back-of-envelope estimate."
• "I'll assume [X] — that seems like a reasonable estimate."
• "Rough order of magnitude: [number]"
• "This gives us [result] — let's round to [clean number] for simplicity."

Why B is the model trade-off answer: honest about limits + mitigation strategies

Discussing trade-offs is the core skill in system design interviews:

• Restates why you chose it: ACID, schema enforcement, complex queries
• Names the limitation honestly: write throughput is limited by primary
• Proposes mitigations: read replicas + cache layer
• Shows next steps: partitioning/sharding if needed
• Engineers with judgment: "start simple, add complexity when needed"

Trade-off vocabulary:

• "The main trade-off here is [X] vs. [Y]."
• "This works well for [use case] but struggles with [limitation]."
• "We can mitigate [problem] by [solution]."
• "I'd start with [simple approach] and move to [complex approach] if we hit [threshold]."

Why B demonstrates technical depth + decision reasoning

This answer shows you know the options and can choose between them:

• Names the choice: LRU
• Explains the mechanism: evicts least recently accessed
• Connects to use case: matches typical web access patterns
• Compares to alternative: LFU — better for stable hotspots, higher overhead
• Shows pragmatism: "start with LRU and monitor hit rate"

Cache vocabulary for interviews:

• LRU (Least Recently Used) / LFU (Least Frequently Used) / FIFO
• "Cache hit rate" / "cache miss" / "cache invalidation"
• "Cache-aside" (lazy loading) vs. "write-through" vs. "write-behind"
• "Eviction policy" / "TTL (time to live)"

Why B is comprehensive: layered defense in depth

This answer demonstrates systems thinking across multiple layers:

• Distinguishes predictable vs. sudden: different strategies for each
• Auto-scaling: handles incremental increases automatically
• CDN: offloads static traffic from the origin
• Rate limiting / queueing: protects backend capacity
• Cache: absorbs database read load
• Circuit breakers: prevents cascading failures

Resilience vocabulary:

• "Horizontal scaling" (more instances) vs. "vertical scaling" (bigger instances)
• "Auto-scaling group" / "elastic scaling"
• "Circuit breaker pattern" / "retry with exponential backoff"
• "Graceful degradation" / "load shedding"
• "Rate limiting" / "throttling" / "back-pressure"

Why C is the model reflection: specific, prioritised, honest about trade-offs

"What would you do differently" is a self-awareness question. The right answer is:

• Lists specific gaps: observability, multi-region, indexing — not vague "more features"
• Explains why each matters: monitoring for production visibility, multi-region for latency
• Acknowledges what was simplified: "the schema I sketched is simplified"
• Shows engineering judgment: "these are real trade-offs I'd resolve in production"

Why A fails: no design is perfect under interview time pressure. Saying "nothing" suggests lack of self-awareness.

Self-reflection vocabulary:

• "Given more time, I'd also consider [improvement]."
• "I simplified [X] for this exercise — in production I'd [better approach]."
• "The weakest part of my design is [component] — here's how I'd address it."