Most people do not fail the system design round because they have never heard of a cache. They fail because they learned system design by reading, and the round is a conversation. You get about 45 minutes, a one-line prompt, and an interviewer who keeps asking what happens when the box you just drew dies.
That gap is the reason I am wary of most advice on picking a system design interview course. The usual lists compare lesson counts and prices. The more useful question is what the course makes you do. This post covers what the round scores, the question types by pattern, one worked example, and the common mistakes. I teach it with the course we rebuilt this autumn, System Design Interview Prep: AI Coach Edition, because it is easier to show than to describe. It is for engineers with a loop coming up, and for PMs and TPMs who have a technical round and want to learn system design from the ground up.
What a system design interview course has to teach
A design round is graded on a handful of signals, and they are not about which technologies you can name. The first module of the course spends a whole session on this, because knowing what the interviewer writes down changes how you use the 45 minutes.
There are four steps on one clock. Scope the problem in about 8 minutes. Sketch a high-level design in about 12. Go deep on two or three hard parts for about 18. Wrap up in about 5. The deep dive gets the largest block because that is where your level shows. If you are still clarifying requirements at minute 15, you will not get there.
I will not repeat the fundamentals here. System Design Interviews 101 covers the five habits that carry a round, and How to Prepare for System Design Interviews Using AI covers mock practice on a live architecture board. This post is about the learning path that comes before the mocks.
System design interview questions, grouped by pattern
The prompts change from company to company. The shapes underneath repeat. If you can name the shape in the first two minutes, the interviewer can follow your plan, and you know which part deserves the deep dive.
| If the prompt needs | The pattern | Example questions |
|---|---|---|
| Many more reads than writes | Cache, CDN, replicas | Design a URL shortener. Design Pastebin. |
| A feed or a search box | Fan-out, precomputed views, a trie | Design the Facebook News Feed. Design typeahead. |
| Protection from abuse | Counters and buckets | Design an API rate limiter. |
| One event, many reactions | Queues, pub/sub, retries | Design a notification system. |
| Slow or retryable work | Workers and schedulers | Design a web crawler. |
| Data that outgrows one machine | Partitioning, replication, quorums | Design a key-value store. |
| Scarce inventory or money | Transactions, holds, idempotency | Design Ticketmaster. |
| The server pushing to clients | WebSockets, presence, ordering | Design Facebook Messenger. |
| Large media | Object storage, transcoding, CDN | Design YouTube or Netflix. |
| A model calling tools | Agent loops, retrieval, guardrails | Design ChatGPT. Design a real-time voice AI. |
Many prompts combine two or three. A food delivery app is a transaction (the order), an event fan-out (the kitchen, the courier, the receipt), and a real-time problem (the courier’s dot on the map). A strong candidate says so, then asks which part to design first.
The last row is newer. Interviewers now ask about AI systems, and the questions have their own numbers: sizing in tokens, keeping GPUs busy, the latency budget of a voice agent. A course written a few years ago will not have them.
A worked example: from one server to 50 million users
The second module is the one I would show anyone deciding whether to learn system design this way. Coach Nora, the voice coach for the whole course, grows a photo app called Lumen from a single machine to two regions. Every step follows the same loop: what broke, the box we add, what it costs.
On launch day Lumen runs on one server that holds the app, the database and the photos. Nora asks what about it should worry you. At about a thousand users the database gets its own box, and the cost is a network hop on every query. At ten thousand users the web server sits at 96 percent CPU and she stops and asks you to choose: a bigger server, more servers behind a load balancer, or a faster database?
The answer is more servers. A bigger box hits a ceiling and still fails alone. What makes the session work is her next question: “We just drew a new single point of failure. Which box?” It is the load balancer you just added. That is the habit the round rewards. Every fix creates the next problem, and you should be the one to name it.
- 1Launch day: one serverApp, database and files on one machine.
- 21,000 users: the database gets its own boxCost: a network hop on every query.
- 310,000 users: a load balancer and three web serversWeb CPU drops from 96 percent to 35.
- 4100,000 users: a cache in front of the databaseCost: data can be stale until it expires.
- 51 million users: a CDN and read replicasThe primary dies at peak. A replica is promoted.
- 610 million users: four shardsReplicas never add write capacity. Shards do.
- 750 million users: two regionsOne goes dark. Failover works only if the data is already there.
The session keeps going. Traffic triples and you predict what breaks first (the database, because stateless web servers multiply in minutes and the one machine holding every row does not). A cache takes the hot reads at a reasoned 90 percent hit rate. A user posts a photo, refreshes, and it is not there, which is replication lag and not a failure. Writes reach 25,000 a second and you have to say why more read replicas will not help. By the end you have placed about a dozen boxes, and you can say why each one is there.
How the course is built: read, train, mock
The course has 19 modules. A module has up to three parts. You read the notes, which are written the way a coach would explain the topic and end with a checklist and practice questions. You train with Nora in a voice session of about 20 to 25 minutes, where she builds the system in her lab and stops to question you. Then you take a mock interview on that topic and get a written report scored against a rubric.
On the public course page that adds up to 43 voice sessions: 20 coach sessions (18 in the 3D lab, plus two earlier slide-based ones we kept) and 23 mock interviews. There are also 38 readings, counting a pre-read for most mocks. To be exact about the shape: the five foundation modules and two of the later ones have a reading and a coach session but no dedicated mock, and a few modules have several mocks.
| # | Module | Mock interviews |
|---|---|---|
| 1 | The interview framework and rubric | |
| 2 | From one server to millions of users | |
| 3 | Back-of-the-envelope estimation | |
| 4 | Building blocks: caches, CDNs, load balancers, APIs, queues | |
| 5 | The data layer: replication, sharding, the hash ring, CAP | |
| 6 | Unique IDs and the URL shortener | Pastebin |
| 7 | News feeds and typeahead | Facebook News Feed, Twitter, Typeahead, Twitter Search |
| 8 | Rate limiting | API Rate Limiter |
| 9 | Event-driven systems and notifications | Notification System |
| 10 | Async jobs, schedulers and crawlers | Web Crawler |
| 11 | Distributed storage | Key-Value Store |
| 12 | File sync | Dropbox |
| 13 | Transactional systems | Ticketmaster |
| 14 | Batch and stream pipelines | |
| 15 | Real-time chat and collaboration | Facebook Messenger, Uber Backend, Yelp / Nearby Friends |
| 16 | Media streaming | YouTube / Netflix, Instagram |
| 17 | Agentic AI | ChatGPT, Claude Code, AI Customer Support, Real-Time Voice AI, File Uploader, LLM Query Batching |
| 18 | Reliability and security | |
| 19 | Design It Live (capstone) | Design It Live |
Most of the mocks run on a live architecture board with a senior engineering manager persona: you drag components, wire them up, and defend the design. The capstone is different. An interviewer named Morgan lets you pick a photo-sharing app, a chat app or a ride-hailing app, and draws your design in 3D as you say it. Then comes the stress test: traffic times ten, a box dies, a region goes dark.
The capstone report scores six parts, each from 1 to 5, and the weights say a lot about where the round is won.
The lab: why the coach builds the system while she talks
The part of this course I care most about is the lab. We call it a Motion App: a live app beside the call that the voice agent controls while it talks, and that tells the agent what you tap. The idea is that the motion is the lesson. You do not look at a finished diagram of a sharded database. You watch the primary overheat, and then you watch four shards take its place.
The lab for this course is called Arch Lab. A few of its scenes:
- A system that grows. In module 2, a new box rises into the scene with a ring around it, and traffic flows along the links as small dots. A hot box glows and its meter turns red. A failed box greys and tips over, and its traffic moves to its siblings.
- The hash ring. In module 5, servers and keys sit on one circle. A fifth server, E, joins between B and C, and only the keys between B and E move. Everything else stays put. That one animation explains consistent hashing better than a page of text.
- The fixed window. In module 8, the limit is 5 requests a minute and you are asked how many got through between 0:30 and 1:30. The answer is 10, because every clock minute is legal and one rolling minute still sees double the limit.
- A design drawn from your voice. In the capstone, every box you name appears in the scene, and you can also tap one from a palette to add it.
The scenes share one rule, which we call predict then reveal. On a predict beat the coach asks a question and the lab shows a few chips. You tap one, or say it. The lab only shows “Locked in”, and Nora asks you why. Then the scene moves to the truth and your guess turns right or wrong. The course has dozens of these beats, and a correct guess is never shown before you commit.
We have invested in these labs across our courses: Arch Lab for system design, Stats Lab and Query Lab for data science, an Estimation Lab for estimation questions, a Deploy Lab for the forward deployed engineer interview, a Defense Lab for security engineers, and Merger, DCF and LBO labs for investment banking.
Is this a free system design course?
The course content is free. There is no separate course fee, and nothing is locked behind a higher tier: every reading, coach session and mock in the course is included. The voice sessions use the minutes on your plan, the same as any other session on Tough Tongue AI, and you can start on the free plan. The readings need a sign-in.
For context, Tough Tongue AI builds voice AI agents, mostly for sales teams. Interview courses like this one are where we push what a voice agent can teach, and the full list is on the courses page.
I would still read alongside it. The System Design Primer on GitHub is a good free reference, and Designing Data-Intensive Applications is the book to pick up when you want depth on storage and replication. Text courses such as Grokking the System Design Interview give you many reference designs in one place. What none of them can do is ask you a question and wait for your answer.
Common mistakes a course should train out of you
The readings end with a list of traps, and the same few come up in mock reports again and again.
- Boxes before questions. Drawing for ten minutes before asking how many users there are. The requirements signal takes the first hit.
- Over-engineering. Kafka, microservices and three regions for an app with five thousand users. It tells the interviewer you were not designing for the problem in front of you.
- Technologies without reasons. “We will use NoSQL, it scales” is the weak answer. The strong one names the option you did not pick and why.
- Never reaching the deep dive. Fifteen minutes on requirements leaves no time for the part that sets your level.
- Ending with “I think that is everything.” Name the weakest part of your design before they do, and say what changes at the next 10x.
A plain reading course can tell you these. You only stop doing them when someone catches you in the act, which is why I would count the mocks and the questions a course asks, not its lessons.
A two-week plan for the course
Two weeks is enough if you have built backend systems before. If distributed systems are new to you, stretch week one to two weeks and keep week two as it is.
Week one: foundations. Do modules 1 to 5, one a day. Read the notes first, then take the coach session the same day while the reading is fresh. After module 3, practise one estimate a day on paper: requests per second, storage per year, and what the numbers tell you to build. Use the weekend to redo the module 2 session and try to call every predict beat correctly.
Week two: patterns and mocks. Pick the patterns your target companies ask about. A reasonable default is modules 6, 7, 8, 13, 15 and 16, plus module 17 if the company builds AI products. For each one, do the reading and the coach session, then the mock. Read the written report and write down one thing to fix before the next mock. Finish with module 18 and the Design It Live capstone, and run the capstone twice with different problems.
Three or four full mocks, timed and out loud, is the minimum before a real round. If you are also preparing for coding rounds, this post on practising coding interviews with AI follows the same idea, and our comparison of AI mock interview platforms covers the wider field if you want to see other tools.
Closing thought
Reading about system design helps less than most people expect. What helps is someone who will not let a box sit on the board without asking what happens when it dies. A good system design interview course should give you that person on demand, and something to look at while the two of you talk.
That is what we tried to build. Start with module 2 of the course, watch one server become fifty million users, and see how many of the predictions you call.
