How to Present a System Design
Knowing system design isn't enough — you must communicate it clearly under time pressure. A structured framework prevents rambling, ensures coverage, and demonstrates senior engineering thinking.
The RADIO Framework
Step 1: Requirements (5 min)
Goal: Show you don't make assumptions. Ask questions to constrain the problem.
- Functional: "Should we support X? What about Y?"
- Scale: "How many users? Read/write ratio? Peak traffic?"
- Constraints: "Latency targets? Consistency requirements? Budget?"
- Prioritize: "Given 40 minutes, I'll focus on the core flow and these 2 deep-dives."
⚠️ Don't spend more than 5 minutes here. Get enough to start, revisit as needed.
Step 2: High-Level Architecture (10 min)
Goal: Draw the boxes and arrows. Show the data flow end-to-end.
- Start with the user action → work through to storage
- Name each component clearly (not "this thing")
- Show separate read and write paths if different
- Include: clients, load balancer, services, cache, database, queues
Step 3: Deep-Dive (15 min)
Goal: Demonstrate depth, not breadth. Pick 2-3 critical components.
- Ask: "Which component would you like me to dive into?" (shows collaboration)
- Discuss trade-offs explicitly: "We could do X or Y. X gives us… but costs…"
- Show you understand failure modes: "What happens when this component fails?"
- Back claims with numbers: "At 100K QPS, a single Redis node handles this because…"
This is where strong candidates differentiate themselves.
Steps 4-5: Infrastructure & Operations (10 min)
Infrastructure
- Database choice with reasoning (not just "use Postgres")
- Scaling strategy: horizontal partitioning, read replicas, caching layers
- Deployment: multi-region, CDN, container orchestration
Operations
- Monitoring: what metrics would you alert on?
- Failure modes: what breaks first? How do you degrade gracefully?
- Deployment: blue-green, canary, rollback strategy
Communication Tips
| Do ✓ | Don't ✗ |
|---|---|
| Think out loud — share your reasoning | Go silent for 2 minutes while thinking |
| State trade-offs: "A vs B, I choose A because…" | Present one option as the only possible answer |
| Ask interviewer preferences: "Should I dive into X or Y?" | Monologue for 20 minutes without checking in |
| Start broad, then zoom in | Jump straight into database schema details |
| Acknowledge limitations: "In a real system, we'd also need…" | Claim your design is perfect and handles everything |
Good vs Bad Diagram Style
Common Mistakes
- Diving into details too early — "Let me design the database schema" before showing the overall architecture
- Not asking questions — making assumptions about scale, features, constraints
- Over-engineering — adding Kafka, microservices, and ML when the problem doesn't need it
- Ignoring non-functional requirements — no mention of latency, availability, or failure modes
- Not stating trade-offs — every design choice has costs; say them out loud
- Monologuing — not checking in with the interviewer, missing signals to pivot
Strong vs Weak Answer: "Design Twitter"
Weak: "I'd use React for the frontend, Node.js for the backend, and MongoDB for the database. Here's the tweet schema..." (jumps to details, no architecture, no trade-offs)
Strong: "Let me clarify requirements — are we focusing on the timeline feed, posting, or search? ... Given 500M users and a 100:1 read/write ratio, the key challenge is fan-out. I'll draw the high-level architecture first, then deep-dive into the fan-out strategy where push vs pull is the central trade-off..." (structured, asks questions, identifies the hard problem)
Interactive: Practice Timer & Checklist
Structure Your Answer
Start the timer and check off each phase as you practice.