How to prepare for a system design interview in four weeks
The questions and guides in the order that builds on itself: vocabulary and numbers, then data at scale, then asynchrony and correctness, then breadth and rehearsal. About an hour a day. Skip ahead freely: the sequence matters more than the calendar, and the last week is the one people cut and then regret cutting.
83 questions exist in total; the plan uses the ones that teach a pattern you will be asked about.
The vocabulary and the numbers
Before any question is worth attempting you need the building blocks and the arithmetic. This week is mostly reading, with one question to prove the loop works.
Days 1–2 · How the hour runs, requirements and estimation
Learn the five-step structure, how to put a number on every requirement, and the number ladder. By the end you should be able to turn "100 M daily users" into requests per second without writing anything down.
Read: How to run a system design interview · Functional vs non-functional requirements in system design · Back-of-envelope estimation
Days 3–4 · Scaling, load balancing, caching
The three moves behind most answers: add stateless replicas, spread the traffic, keep the hot set in memory. Learn cache-aside and why you delete rather than update the key.
Read: Scalability fundamentals · Load balancing · Caching
Days 5–7 · First question, both modes
Study it, then practise it the next day. The gap between reading it and producing it is the whole point of the site, and this is where you feel it for the first time.
Read: CDNs and edge computing
Work through: Design a URL Shortener (watch it)
By the end of week 1: You can state a read-heavy design with a cache and a CDN, and defend a TTL with a number.
Data at scale
Where the data lives, how it is split, and what you promise about it. This is the week that most candidates are weakest on and interviewers probe hardest.
Days 1–2 · Databases and modelling for reads
Access patterns first, schema second. Learn to say the write amplification of a design out loud.
Days 3–4 · Sharding and replication
Consistent hashing, hot shards, quorums, and what a failover loses. The distributed cache question is the purest drill for all four.
Read: Sharding and partitioning · Replication and consistency
Work through: Design a Distributed Cache (watch it)
Days 5–7 · Fan-out and the celebrity problem
Push versus pull, and the hybrid nobody reaches without being pushed. Practise this one twice; the second attempt is where the threshold argument becomes yours.
Work through: Design a News Feed (watch it)
By the end of week 2: You can pick a shard key, justify it against the queries, and say what breaks when one key goes viral.
Asynchrony, real time and correctness
Queues, streams, sockets and the things that go wrong when a request spans more than one service.
Days 1–2 · Queues and streams
Delivery guarantees, ordering, consumer lag, and why exactly-once is about effects rather than delivery.
Read: Message queues and event streams · Batch and stream processing
Work through: Design a Web Crawler (watch it)
Days 3–4 · Real time
Connection tiers, registries, fan-out, resync from a cursor. Size a connection fleet from a concurrency number.
Read: Real-time systems: WebSockets, SSE and push
Work through: Design Slack (watch it)
Days 5–7 · Money and idempotency
Idempotency keys, the outbox, sagas versus 2PC, and the state machine with an unknown outcome. The hardest correctness question on the site.
Read: Distributed transactions and idempotency
Work through: Design a Payment System (watch it)
By the end of week 3: You can make any write path safe to retry and explain what the user sees while it is in flight.
Breadth, then rehearsal
Fill the remaining patterns, then stop learning and start performing. The last week is deliberately light on new material.
Days 1–2 · Machine-shaped problems
Scarce capacity, admission control, streaming responses. The inference question is reported at every AI company and at most large ones now.
Read: API design · Rate limiting and resilience
Work through: Design an LLM Inference Service (watch it) · Design a Rate Limiter (watch it)
Days 3–4 · Pick your two weakest
Use the practise-next card on the home page. Redo the two lowest grades, aiming to beat them without reading first.
Days 5–7 · Full rehearsals
One timed run a day on a question you have not done recently, out loud, to the clock: 5 minutes requirements, 5 estimates, 15 design, 15 deep dives, 5 wrap-up. Say it to a person or a recording, not to yourself in your head.
By the end of week 4: You can run the whole hour unprompted, out loud, without looking anything up.
How to prepare: questions people ask
How do you prepare for a system design interview?
Learn the building blocks and the arithmetic first, then work through questions in an order that builds on itself: caching and estimation, then data at scale, then asynchrony, real time and correctness, then full rehearsals out loud. About an hour a day for four weeks is enough for most loops, as long as the last week goes on timed rehearsal rather than more reading.
How long does it take to prepare for a system design interview?
About four weeks at an hour a day: one week on the vocabulary and the numbers, one on data at scale, one on queues, real time and correctness, and one on breadth and full rehearsals. Someone who already designs distributed systems at work can compress the first two weeks, but should not skip the rehearsals.
What should you study first for system design interviews?
Start with how the hour runs and back-of-envelope estimation, then scaling, load balancing and caching. Those cover the moves behind most answers: add stateless replicas, spread the traffic, keep the hot set in memory, and turn daily users into requests per second without writing anything down. Then do one full question, such as a URL shortener, to prove the loop works.
How do you practise system design interviews?
Out loud and under a 45-minute clock. Walk through how a strong candidate answers a question, then sit the same question a few days later without looking, and compare what you said with the reference. Recall fades faster than you expect, so redo the questions you scored well on before the real interview.
After the four weeks
Keep one question a day in rotation. Walk through a question once, then sit the same question as a timed mock a few days later without walking through it again: the debrief tells you what you actually kept. Recall fades faster than you expect, so redo the mocks you scored well on a month ago before a real interview.