System Design for Interview Prep

This is a no-nonsense course on the classic system design interview problems. You won’t get finished solutions to memorize; instead, this course teaches one framework and how to run it, step by step, across four full problems.

You don't need any prior course or experience to start. That’s because every building block these designs use, from caching and queues to replication, sharding, consistent hashing, and CDNs, is explained from scratch, in plain language, right inside the problem that needs it.

The course opens with what the interviewer is really grading, and how six steps fit into a 45-minute interview slot. You clarify the requirements, estimate only the numbers that decide something, define the API, and draw the simplest version that works. Then you deep dive into the one or two decisions that define the problem, and then start searching for the bottleneck. Every problem starts the way it does in an actual interview-with one vague sentence, like "design a notification system." From there, you ask the questions whose answers genuinely changes the design. You pick the data store from the access patterns, instead of guessing at a technology. You get something working end to end, and then break it with one concrete number that forces in the next component.

Each of the four problems is designed twice: first as the simplest version that works, and then again under load, once it breaks.

First is the URL shortener. It starts with a simple choice: do you hash the URL, or use a counter? Then one link goes viral, hammers a single database row, and you add the cache that absorbs it. Second is the rate limiter. It starts with a fixed window, moves to a sliding window, and then a token bucket. And once you have many gateways, a new question comes up-“where does the counter live?” Third is the notification system. It starts as one send call, and grows into a queue per channel, retries, a dead-letter queue, and the outbox. And, finally, the news feed. It stops building feeds when someone opens the app, and precomputes them instead; a fan-out worker copies each new post into every follower’s feed. Then a celebrity posts, and that one account forces a hybrid design.

The walkthroughs also give you a few ready-made lines you can say to the interviewer while you think. Every problem ends with a Curveball Byte: the interviewer changes one assumption in the middle of your answer, and now you figure out what breaks, what has to change, and what the new version costs. That’s the moment most candidates lose the interview.

The hands-on labs run the systems you designed. You fire two hundred requests at one short link and watch every single one land on the database. You hit the rate limit past ten requests a minute. You see a notification delivered twice, while the failed ones wait in the dead-letter queue. And you watch a worker copy a new post into every follower's feed-before anyone even opens the app. Each lab comes with a hint and a full solution.