System Design Interview Framework

System design interviews are structured conversations, not open-ended architecture whiteboarding sessions. The interviewer wants to see how you think, communicate, and handle trade-offs — not whether you've memorised the Twitter architecture. This plan teaches you a repeatable framework (RADIO) that works for any system, then builds your depth in each phase, and finishes with full mock walkthroughs. The RADIO Framework System design interviews are not free-form architecture discussions. They are structured assessments with a clear rubric. The single most effective thing you can do is adopt a consistent, named framework and execute it reliably. The RADIO framework does exactly that. What is RADIO? RADIO is a 5-phase structure for system design interviews: Name Time Requirements 5 min A Define the contract between client and server Data Model 5 min I Draw and narrate the core architecture Optimization 10 min | Total: 45 minutes. Why Structure Matters Without a framework, candidates typically: Spend 20 minutes on requirements and run out of time for the design Jump immediately to infrastructure and forget to ask about scale Cover topics in random order, which makes them look disorganised Interviewers score structure explicitly. At companies like Meta, Google, and Amazon, "structured communication" is a named evaluation dimension. The Framework in Practice Phase R — Requirements (5 minutes) Goal: agree on what you are building and at what scale. Ask: "What are the top 3 things a user can do in this system?" "What scale should I design for — how many daily active users?" "Is there a latency or availability SLA I should know about?" "What is explicitly out of scope for this interview?" Once you have answers, summarise them back: "So I'll design a system that handles X, Y, Z for 100M DAU with p99 latency under 200ms. I'll set aside features A and B. Does that sound right?" Phase A — API Design (5 minutes) Goal: define the interface your system exposes. Design 3–5 endpoints that cover the core use cases. Use REST or gRPC as appropriate. Example for a URL shortener: This phase forces you to think like a product engineer, not just a systems engineer. Phase D — Data Model (5 minutes) Goal: choose your database(s) and sketch key schemas. Which database type fits (SQL, NoSQL, graph, time-series)? What are the 2–3 core tables/collections? What are the primary keys and foreign keys? What indexes do you need? Phase I — Infrastructure (20 minutes) Goal: draw the system architecture and walk through the happy path end-to-end. Draw: clients → load balancer → services → databases/caches/queues → CDN/storage. Walk through at least 2 core flows (e.g., write path and read path). Phase O — Optimization (10 minutes) Goal: identify and address bottlenecks. Ask yourself: "What breaks first when traffic 10×s?" Then propose targeted solutions: caching, sharding, CDN, message queues, rate limiting. Interview Dialogue: Opening Interviewer: "Design Twitter." You: "I'd love to. Let me start by clarifying requirements before I jump into design — is that okay? [Pause for yes] Great.