Communicating System Design — Think Out Loud

System design interviews test how you think, not just what you know. The structure of your answer matters as much as the content.

The 4-Phase Framework

Phase 1: Clarify Requirements (5 minutes)

Never start designing immediately. Ask questions first.

• Functional requirements — What does the system do?
• Non-functional requirements — Scale, latency, availability targets
• Scope — What's in vs out for this conversation?
• Users — Who uses it? How many? Read/write ratio?

Questions to always ask:

• "How many daily active users should we design for?"
• "What's the expected read-to-write ratio?"
• "Are there latency requirements?"
• "Should I focus on the backend, or include the client?"

Phase 2: High-Level Design (10 minutes)

Sketch the big picture before details.

• API design — Define 2-3 core endpoints
• Core components — Load balancer, app servers, database, cache
• Data model — Key entities and relationships (keep it simple)
• Data flow — How does a request travel through the system?

Draw as you talk:

• Boxes for services
• Arrows for data flow
• Labels for technologies
• Note capacity at each layer

Phase 3: Deep Dive (20 minutes)

This is where you show depth. Pick 2-3 areas based on the problem.

• Database design — Schema, indexing strategy, sharding approach
• Scaling — Horizontal scaling, load balancing, auto-scaling
• Caching — What to cache, TTL strategy, invalidation
• Messaging — Async processing, event-driven patterns, queues
• AI/ML pipeline — Feature store, model serving, A/B testing (if relevant)

Phase 4: Wrap Up & Trade-offs (10 minutes)

End strong by demonstrating engineering maturity.

• Summarise your design in 30 seconds
• Discuss trade-offs you made and why
• Identify limitations — what would break at 100x scale?
• Propose improvements — what would you add with more time?
• Address edge cases — failure modes, data consistency

What Interviewers Actually Score

Whiteboard & Diagram Best Practices

| Do | Don't | |----|-------| | Use consistent shapes (boxes for services, cylinders for DBs) | Draw a wall of text | | Label every component and arrow | Assume the interviewer tracks unlabelled lines | | Use colour or grouping to show layers | Crowd everything into one corner | | Write capacity numbers on components | Leave scale ambiguous | | Erase and redraw when the design evolves | Scribble corrections on top of existing drawings |

How to Handle "Design X" Questions

A repeatable approach for common prompts:

"Design a URL shortener"

• Clarify: Write-heavy or read-heavy? Custom URLs? Analytics?
• Key decisions: Hashing vs counter, SQL vs NoSQL, caching layer
• Deep dive: Collision handling, redirect latency, analytics pipeline

"Design a chat application"

• Clarify: 1:1 or group? Message persistence? Read receipts?
• Key decisions: WebSocket vs polling, message storage, presence service
• Deep dive: Fan-out strategy, delivery guarantees, offline sync

"Design an ML recommendation system"

• Clarify: Recommendation type? Real-time or batch? Cold start handling?
• Key decisions: Collaborative vs content-based, feature store, serving infra
• Deep dive: Model training pipeline, A/B testing framework, feedback loops

Time Management Tips

• Set a mental timer for each phase — don't let Clarify eat into Deep Dive
• If stuck, say so — "I'm not sure about the best approach for X, but here's how I'd reason through it..."
• Check in every 10 minutes — "Does this direction make sense? Should I go deeper here?"
• Save 5 minutes for wrap-up — summarising well leaves a strong final impression

Practice Checklist

• [ ] I can explain the 4-phase framework from memory
• [ ] I've practised at least 3 different "Design X" problems with a timer
• [ ] I naturally verbalise my thinking process while drawing
• [ ] I check in with my interviewer at transitions between phases
• [ ] I always discuss trade-offs, not just the "happy path"
• [ ] I can sketch clean, labelled diagrams quickly