Run a system design interview

A system design interview starts with a deliberately vague prompt such as “Design a URL shortener.” There is rarely one right answer. The interviewer is watching how you handle ambiguity, make reasonable assumptions, communicate trade-offs, and drive toward a design that works. A repeatable framework stops you from jumping straight to boxes and arrows.

1. Clarify requirements. Functional requirements say what the system does (“users can create short links”). Non-functional requirements say how well it must do it: scale, latency, availability, consistency, durability.
2. Estimate scale. Rough requests per second, storage, and bandwidth - just enough to guide decisions.
3. Define the API and data model. The key endpoints and the main entities with their access patterns.
4. Sketch the high-level design. Clients, load balancers, services, data stores, caches, and queues.
5. Deep-dive. Pick the hardest parts (often where the interviewer steers you) and go into detail: bottlenecks, failure modes, scaling limits.
6. Wrap up. Summarize trade-offs, what could fail, and what you would build next.

A 45-minute budget, as a starting point: requirements 5 minutes, estimation 5, API and data model 5, high-level design 10, deep dives 15, wrap-up 5.

The time budget is a guide, not a script. Some interviewers skip estimation; others spend the whole deep dive on one component. What matters is that you lead the conversation, check in with the interviewer at each transition (“Does this high-level design look reasonable before I go deeper?”), and adapt when they steer you.