The Universal Design Framework
Every system design interview follows the same six-step arc. Internalize this method and you'll never freeze on a prompt again — you'll always know what to do next.
- 1
Clarify requirements
3-5 minTurn a vague prompt into a concrete, scoped problem.
What to do
- Separate functional from non-functional requirements
- Who are the users and what are the top 2-3 use cases?
- What's explicitly out of scope?
- What are the consistency / latency / availability targets?
Avoid
- Jumping straight to a diagram
- Designing for requirements nobody asked for
- 2
Estimate scale
3-5 minDerive the numbers that will drive every later decision.
What to do
- QPS: daily volume ÷ 86,400, then apply a peak factor
- Storage: bytes per record × records × retention
- Bandwidth: request/response size × QPS
- Read:write ratio — it decides your caching and replication
Avoid
- Skipping the math
- Precision theater — round aggressively
- 3
Define the API
3-5 minPin down the contract between client and system.
What to do
- List the core endpoints (verb, path, params)
- Decide REST vs RPC vs GraphQL and why
- Think about pagination, idempotency keys, versioning
Avoid
- Vague endpoints
- Ignoring idempotency for writes
- 4
High-level design
8-10 minDraw the boxes: clients, LB, services, data stores, queues.
What to do
- Start with the simplest thing that works
- Show the request flow end to end
- Separate read and write paths if they differ
Avoid
- Over-engineering before there's a bottleneck
- Boxes with no data flow between them
- 5
Deep dive
10-15 minGo deep on the 1-2 components the interviewer cares about.
What to do
- Data model and storage choice (SQL vs NoSQL, partitioning)
- The hardest part: the feed, the matching, the consistency
- Trade-offs — always state what you're giving up
Avoid
- Staying shallow everywhere
- Refusing to commit to a choice
- 6
Identify & resolve bottlenecks
5-8 minFind where it breaks at scale and fix it.
What to do
- Single points of failure → replicate
- Hot keys / hot partitions → shard or cache
- Add caching, CDN, read replicas, async processing
- Discuss monitoring and what you'd alert on
Avoid
- Declaring it 'done'
- Adding components with no bottleneck to justify them