Book Interview →
System Design

How to Crack a System Design Interview

A step-by-step framework for structuring and delivering a winning system design interview — from requirements gathering to deep-dives.

  1. 1

    Clarify Requirements (5 min)

    Never start drawing before you understand what you're building. Ask: What are the functional requirements (core features)? What are the non-functional requirements (scale, latency, consistency)? Who are the users and what actions do they take? Are there any constraints (budget, existing infra, team size)? Write a 2–3 sentence problem statement and get the interviewer to confirm.

  2. 2

    Estimate Scale & Capacity (3–5 min)

    Back-of-the-envelope calculations signal engineering maturity. Estimate: Daily/Monthly Active Users (DAU/MAU). Reads vs writes ratio (e.g., 100:1 for Twitter). Storage needed per year. Peak QPS (queries per second) = (DAU × avg requests/day) / 86400. These numbers will drive every design decision.

  3. 3

    Define the API (3–5 min)

    Sketch the core REST/gRPC endpoints or message contracts. For each endpoint define: method, path, request body, response shape, and auth requirement. Example for URL shortener: POST /shorten { url } → { shortCode } GET /{shortCode} → 301 redirect. This forces you to think about interfaces before internals.

  4. 4

    High-Level Architecture (10 min)

    Draw the system as boxes and arrows. Typical components: Client → CDN → Load Balancer → App Servers → Cache → Database → Message Queue → Background Workers. Label each arrow with the protocol (HTTP, gRPC, TCP). Explain your choices — why SQL or NoSQL, why synchronous or async. Focus on data flow, not implementation details.

  5. 5

    Deep-Dive Critical Components (10 min)

    The interviewer will steer you here. Common deep-dives: Database schema & indexing strategy. Cache invalidation policy (LRU, TTL). How you handle hot partitions in sharding. Exactly-once delivery in a message queue. Read/write paths through the system. Be proactive — pick the riskiest or most interesting component and deep-dive it yourself.

  6. 6

    Address Bottlenecks & Trade-offs (5 min)

    Every design has trade-offs — acknowledge them explicitly. Ask yourself: What fails under 10× traffic? What's the single point of failure? How do you handle partial failures (circuit breaker, retry with backoff)? What consistency model did you choose and why? Strong engineers don't pretend their design is perfect — they show awareness of its limitations.

  7. 7

    Summarise & Invite Questions (2 min)

    Wrap up with a one-paragraph summary: 'We designed a URL shortener that handles 100K QPS using a stateless app tier, Redis cache with LRU eviction, Cassandra for short-to-long mappings sharded by short code, and a CDN for redirect caching. The main trade-off is eventual consistency on analytics counters.' Then ask: Is there any component you'd like me to expand on?

💡 Pro Tips

  • Think out loud — interviewers evaluate your reasoning, not just your final design.
  • Draw as you talk — a diagram makes the conversation concrete and easier to follow.
  • Use real product analogies — 'similar to how Twitter's Fanout Service works' shows industry awareness.
  • Don't over-engineer early — start simple, then add complexity only when the interviewer pushes scale.
  • Know your numbers: 1M requests/day ≈ 12 QPS. 1 byte × 1B records = 1 GB.
  • Practice on a whiteboard or paper, not just in your head — drawing under time pressure is a skill.
  • Ask clarifying questions throughout — it's a collaboration, not an exam.