System design questions are open-ended on purpose — the interviewer wants to see how you think, not a memorised answer. The trick is to follow a repeatable framework so you never freeze. Use these five steps for any problem.
Step 1 — Clarify requirements
Never start drawing boxes immediately. Spend the first few minutes narrowing the scope:
- Functional requirements — what the system must do (e.g., 'shorten a URL and redirect it').
- Non-functional requirements — how it must behave: scale, latency, availability, consistency.
- Out of scope — agree what you will not build, so you don't run out of time.
Step 2 — Estimate the scale
Back-of-the-envelope numbers drive every later decision. Estimate:
- Traffic — reads/writes per second (and the read:write ratio).
- Storage — data size per record × records per day × retention.
- Bandwidth and memory for caching the hot dataset.
A read-heavy system points to caching and replicas; a write-heavy one points to sharding and queues.
Step 3 — Define the API and data model
Sketch the core API endpoints and the main entities/tables. This grounds the discussion in something concrete before you scale it.
Step 4 — High-level design
Draw the major components — client, load balancer, application servers, database, cache, and any queues or blob storage — and show how a request flows through them. Keep it simple first; you will refine it next.
Step 5 — Deep dive & find bottlenecks
Now zoom into the hard parts and address scale: add caching, replication, sharding, CDNs or async processing where the numbers demand it. Explicitly call out single points of failure and how you remove them. Discussing trade-offs here is what separates strong candidates.