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. 1

    Clarify requirements

    3-5 min

    Turn 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. 2

    Estimate scale

    3-5 min

    Derive 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. 3

    Define the API

    3-5 min

    Pin 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. 4

    High-level design

    8-10 min

    Draw 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. 5

    Deep dive

    10-15 min

    Go 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. 6

    Identify & resolve bottlenecks

    5-8 min

    Find 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