The Candidate Who Designed a URL Shortener in 5 Minutes
In a Google L5 interview, a candidate jumped straight into database schema and hashing algorithms within 30 seconds of hearing 'design a URL shortener.' They built an impressive technical solution - and got rejected. Why? They never asked about scale (100 URLs vs 100 billion), never discussed read/write ratios, never considered geographic distribution. They solved the wrong problem brilliantly. RESHADED exists to prevent this: a structured framework that ensures you cover every dimension of system design before diving into solutions.
The best system design interviews are not about finding the 'right' architecture. They are about demonstrating a systematic approach to breaking down ambiguous problems, making informed decisions, and articulating trade-offs clearly. RESHADED gives you that system. Think of it as a pilot's pre-flight checklist: experienced pilots still use checklists because they prevent costly mistakes under pressure.
The RESHADED Checklist
RESHADED Framework:
Letter Phase Time Key Questions
------ ------------------- ------ ----------------------------
R Requirements 3 min What does the system do?
Functional + non-functional
Ask 3-5 clarifying questions
E Estimation 3 min DAU? Reads/sec? Writes/sec?
Storage/day? Bandwidth?
S Storage Schema 3 min What data? SQL vs NoSQL?
Key tables, indexes
H High-Level Design 8 min Architecture diagram
All major components
Boxes and arrows
A APIs 3 min Endpoints, request/response
REST vs gRPC vs GraphQL
D Data Flow 5 min Trace ONE request through
the entire system end-to-end
E Evaluation 5 min Does design meet NFRs?
Scale? Latency? Availability?
Where does it break?
D Deep Dives 10 min 2-3 hardest sub-problems
Follow interviewer cues
This is where L5 vs L6 shows
Total: ~40 minutes of content in a 45-min interviewWalking Through Each Letter
R - Requirements: The 3-Minute Scoping
The first letter is where most candidates go wrong. They either skip it entirely (jumping to architecture) or spend 15 minutes asking every possible question. The sweet spot is 3-5 targeted questions that nail down scope and scale. For a URL shortener, the perfect questions are: (1) How many URLs per day? (2) What is the read-to-write ratio? (3) Do shortened URLs expire? (4) Do we need analytics (click counts, geo data)? Those four questions determine whether you are building a simple redirect service or a full analytics platform.
E - Estimation: Numbers Drive Decisions
Estimation is not about precision - it is about order of magnitude. 100M DAU creates fundamentally different challenges than 10K DAU. The four numbers that matter: writes per second, reads per second, storage per day, and bandwidth. Each maps directly to an architecture decision. 10K writes/sec means you need database sharding. 1M reads/sec means you need aggressive caching. 10TB/year means you need object storage for media. Show the interviewer that your numbers drive your choices.
S through D - Building and Evaluating
Storage Schema forces you to think about data before services. High-Level Design is the core of the interview - draw all components, label everything, trace the request flow. APIs define the contract between client and server. Data Flow proves your system actually works by walking through a real request end-to-end. Evaluation is where you stress-test your own design - what happens at 10x scale? Where is the bottleneck? This self-critique is what separates senior from junior candidates.
D - Deep Dives: Where Seniority Shows
The final D is where L5 and L6 candidates separate. After building the complete system, you pick the 2-3 hardest sub-problems and go deep. For a URL shortener, that might be hash collision handling and cache invalidation. For a chat system, it is message ordering guarantees and connection management. The interviewer often guides you here - watch for signals like 'tell me more about how you would handle X.' Always pick the technically hardest problem to deep dive on, not the easiest one.
Interview Tip
RESHADED is your safety net against the #1 system design mistake: jumping to architecture before understanding the problem. Start every interview with 'Let me clarify requirements first' (R), then estimate scale (E) before touching any architecture. The framework is not rigid - adapt the order based on the conversation. But mentally check each letter before concluding. Missing even one dimension (like never discussing APIs or data flow) is a red flag to interviewers.
Key Takeaway
RESHADED is a mental checklist, not a rigid script. The letters - Requirements, Estimation, Storage, High-level design, APIs, Data flow, Evaluation, Deep dives - ensure you cover every dimension of system design. The candidates who fail system design interviews almost always skip one of these steps. The candidates who pass demonstrate a complete, structured approach to breaking down complex problems.