System Design Interview Guide: a Step-by-Step Framework

A system design interview checks whether you can turn a vague product idea into a design that works at scale, and whether you can explain your choices. There is rarely one right answer: interviewers look for a clear process, sensible numbers, and honest trade-offs. Use the framework below for a typical 45 to 60 minute round, then practise it on the 22 questions at the end of this page.

1. Clarify requirements (5 min)

Ask who the users are, the core features for this interview, and the non-functional requirements: scale, latency, availability, consistency and data retention. Write them down and agree on scope before drawing anything.

2. Estimate scale (3–5 min)

Rough numbers decide the design: daily active users, requests per second at peak, read-to-write ratio, data stored per day and over five years, bandwidth. Round aggressively; the order of magnitude is what matters.

3. Define the API (5 min)

List the main endpoints or events with their inputs and outputs, for example POST /urls and GET /{code}. This anchors the rest of the discussion in what clients actually do.

4. Design the data model (5 min)

Choose entities, keys and access patterns, then the store: relational for transactions and joins, key-value or wide-column for huge simple lookups, a search index for text, object storage for files.

5. Draw the high-level design (10 min)

Clients, load balancer, stateless services, cache, database, queues and workers. Walk one request end to end so the interviewer can follow the data flow.

6. Deep-dive the hard parts (10–15 min)

Pick the bottleneck the interviewer cares about: hot keys, sharding strategy, cache invalidation, fan-out, ordering, exactly-once processing or consistency across regions. Explain the trade-offs of each option.

7. Wrap up with trade-offs (3 min)

Summarise the design, name its weaknesses and what you would do next: monitoring, failure modes, cost, and how it scales another 10x.

• Load balancing: Spread traffic across stateless servers; health checks remove bad instances.
• Caching: Cache-aside with Redis or Memcached, TTLs, and a plan for invalidation and hot keys.
• Database scaling: Read replicas, indexing, partitioning or sharding by a key that spreads load evenly.
• Message queues: Kafka or RabbitMQ to decouple services, absorb spikes and retry work safely.
• Consistency: Strong versus eventual consistency, quorum reads and writes, idempotency keys.
• Rate limiting: Token bucket or sliding window, per user or per API key, at the gateway.
• CDN and object storage: Serve images and video from the edge; store blobs outside the database.
• Observability: Metrics, logs and traces with alerts on latency percentiles and error rates.

• Jumping into components before agreeing on requirements and scale.
• Adding microservices, Kafka and Kubernetes everywhere without a reason.
• Ignoring failure: what happens when a cache node, a region or a dependency goes down?
• Never naming trade-offs; every choice costs something (latency, money, complexity, consistency).
• Talking silently or for too long; check in with the interviewer at each step.