0 XP · 0 scenes

How to Prepare for a System Design Interview: An 8-Week Plan

By Vivek Kumar Bhardwaj · Updated · 7 min read

A system design round asks you to design something like a URL shortener or a chat app in about 45 minutes. There is no single right answer. The interviewer is watching how you ask questions, estimate, choose between options and explain the trade-offs.

Preparing is mostly two things: build a vocabulary of building blocks (caches, queues, databases, load balancers), then practise using them in a repeatable order. This plan does both in eight weeks, at about one hour a day.

What interviewers look for

  • You clarify the problem first: what must it do (functional), and how big, fast and reliable must it be (non-functional).
  • You use numbers. A rough estimate of requests per second and storage tells you which design is even possible.
  • You start simple, then scale. A working single-server design first, then the bottlenecks.
  • You name trade-offs out loud. Every choice costs something, and saying so is the skill being tested.
  • You think about failure: what happens when a server, a disk or a network link dies.

The 8-week plan

  1. Week 1, foundations. How to approach a design, scale, availability, latency and quick estimates: interview approach, estimation, availability, latency.
  2. Week 2, storage and caching. How data is stored and found fast: caching, indexes, SQL vs NoSQL.
  3. Week 3, scaling data. Copying and splitting data across machines: replication, sharding, consistent hashing.
  4. Week 4, networking and APIs. Load balancing, CDN, API styles, rate limiting.
  5. Week 5, queues and streaming. Message queues, Kafka, delivery semantics.
  6. Week 6, distributed systems core. CAP theorem, quorums, Raft consensus, distributed transactions.
  7. Week 7, reliability. Retries and backoff, circuit breakers, observability, multi-region.
  8. Week 8, full designs, out loud. Do one a day and explain it to a friend or to a mirror: URL shortener, chat app, social feed, rate limiter, ticket booking.

A framework for the 45 minutes

  1. Requirements (5 min). Ask what the system must do and what is out of scope. Agree on the scale.
  2. Estimates (5 min). Requests per second, data per day, total storage. Round numbers are fine.
  3. API and data model (5 to 10 min). The two or three calls that matter and the main tables or records.
  4. High-level design (10 min). Boxes and arrows: client, load balancer, services, database, cache, queue.
  5. Deep dive (10 to 15 min). Pick the one or two hardest parts and go deep. Let the interviewer steer.
  6. Bottlenecks and failures (5 min). What breaks first at 10 times the load? What if a node dies?

Mistakes that cost the most

  • Drawing boxes before asking a single question.
  • Naming a tool (Kafka, Redis) without saying why it fits this problem.
  • Skipping the numbers, so the design is not tied to the real scale.
  • Never mentioning failure, consistency or cost.
  • Waiting for the interviewer to lead. Drive the conversation and check in often.

Start with the system design lessons. Every one has a simulator, so you can break the system and see the trade-off instead of only reading about it. The glossary explains every technical word in plain language.