System design

30 hours · the prerequisite I nearly skipped

I originally left this out, on the reasoning that classical distributed systems design isn't the differentiator for AI roles. That was wrong twice over.

First, the round is real. At experienced-hire level, a general system design interview is standard at big tech and most product companies — and an ML or AI system design round is usually an additional round rather than a replacement. Planning for only the AI version means preparing for half the loop.

Second, it's a prerequisite, not a competitor. You cannot sensibly design a retrieval system without caching, queues, replication, and back-of-envelope estimation. Every AI system design answer is a general system design answer with a model in the middle of it. Attempting AI system design first is why people produce architectures that describe an embedding pipeline in loving detail and never mention how requests reach it.

So: this pillar first, then the AI one. Thirty hours, because the goal is competence at the standard round, not distributed systems expertise.

Is the System Design Primer enough on its own?

No — and it's the most common way this pillar goes wrong. The Primer is an excellent reference: comprehensive, free, and the best topic-by-topic lookup there is. But it's organised as an encyclopedia, not as an interview. It will teach you what a load balancer is and leave you unable to run a 45-minute conversation, which is the thing actually being assessed. Parts of it also predate how people build on cloud services now.

You need three layers, and the Primer is only the third:

1. A delivery framework — how to structure the conversation. Hello Interview, below.
2. Worked case practice — attempting designs and comparing against a good answer.
3. A reference for gaps — the Primer, plus DDIA when something won't stick.

A fully free path works: Hello Interview's free core for the framework, its free question breakdowns plus cases you write yourself for practice, and the Primer as the reference. Alex Xu's book is polish, not a requirement.

Modules

1 · The framework · ~5h

Same principle as everywhere else in this roadmap — have a structure and use it every time, because improvising one under time pressure is what makes strong engineers ramble.

Roughly: clarify functional and non-functional requirements → estimate scale → define the API → data model → high-level design → deep dive on one or two components → identify bottlenecks and failure modes.

• System Design in a Hurry — Hello Interview · work through. Written backwards from what the interview actually requires rather than as a systems course, which is exactly the right shape for a 30-hour budget. Core framework and concepts are free; some question breakdowns are paywalled. Start here — it's the fastest route to a usable framework.

Done when: you can drive the framework end to end on an unseen prompt in 45 minutes, out loud, without notes — and you spend the first five minutes on requirements rather than diagramming.

2 · Building blocks · ~10h

The vocabulary. You need these as tradeoffs you can argue, not definitions you can recite — the follow-up is always "why that and not the other thing."

Load balancing · caching and invalidation · SQL vs. NoSQL and when the choice actually matters · indexing · replication and partitioning/sharding · consistency models and CAP in practice · message queues and event streams · CDNs · rate limiting · idempotency · failure modes, retries, and backpressure.

• The System Design Primer — Donne Martin · reference. Free, enormous, ~300k stars, and the long-time default starting point. Too big to work through linearly — use it as a lookup per topic, and use the included Anki decks, which are the genuinely underrated part.
• Designing Data-Intensive Applications, 2nd edition — Martin Kleppmann & Chris Riccomini, O'Reilly, March 2026 · reference. The deep one, and the second edition rewrites the first around how people actually use cloud services now. Read chapters when a concept won't stick — reading it cover to cover is a 60-hour commitment this budget cannot fund.

Done when: for any building block above, you can state what problem it solves, what it costs, and one situation where it's the wrong choice.

3 · Back-of-envelope estimation · ~3h

A small module that disproportionately signals seniority, because most candidates skip it and then design for a scale they never established.

Latency numbers every engineer should know · QPS from DAU · storage from record size and retention · bandwidth · how many machines that implies.

Practise until it's a 3-minute step rather than a panic. Round aggressively — nobody wants precision, they want to see you reason about orders of magnitude.

Done when: given "design X for 100M daily users," you can produce QPS, storage, and bandwidth estimates in under five minutes and use them to justify a design decision.

4 · Classic cases · ~12h

Six or seven cover the patterns. As with the AI cases: write them, don't read them.

URL shortener · rate limiter · news feed · chat system · notification system · web crawler · nearby-friends or proximity service.

• System Design Interview – An Insider's Guide — Alex Xu · work through. The standard. A 4-step framework, 16 worked questions, 188 diagrams. Attempt each cold before reading the solution — reading solutions is how you end up feeling prepared and performing badly.
• System Design Interview – An Insider's Guide: Volume 2 — Alex Xu & Sahn Lam · reference. More cases, same framework. Only worth it once Volume 1 is genuinely finished.

Done when: six cases written under time, and the framework runs without you consciously recalling the next step.

What I'm skipping

• Distributed systems theory. Paxos, Raft, vector clocks. Fascinating, occasionally asked at infrastructure-specialist level, not on this path. Know that consensus is hard and what it buys you.
• Reading DDIA cover to cover. It's the best book in this pillar and the worst fit for the budget. Reference use only.
• Company-specific architecture blogs. Enjoyable, low interview return, effectively unbounded.
• Low-level design and OOD rounds. A different interview. Prepare separately if it appears on a schedule.

Then what

Once the framework is automatic and the building blocks are arguable, move to AI system design. It reuses this framework wholesale and adds the parts specific to systems built on models — evaluation, retrieval, inference cost, and the failure modes that only appear when a component is nondeterministic.