Design ten real systems end to end, then break each one six ways and defend what you would change — and what you deliberately would not.
Most system design material teaches you to add things. A cache here, a queue there, shard the database, and the answer to every question becomes more infrastructure. That is not what a senior builder does, and it is not what a design review is testing. The actual skill is judgement: given a working design and a specific pressure, knowing what genuinely has to change, what does not, and being able to say why. This course builds that. You start with the lens — how to turn vague requirements into numbers, what each component in your vocabulary actually buys you and what it costs, and the six questions that break any design. Then you apply it ten times, to ten systems you already use: a rate limiter, file storage, notifications, a feed, search, booking and inventory, payments, ride matching, recommendations, and metrics. Each one you design at a high level, then detail down to the data model and API, then break six ways — traffic multiplies by a hundred, a region goes dark, duplicates stop being tolerable, reads have to land under a tenth of a second, data is forbidden from leaving the country, and something you depend on turns unreliable. Every answer names the bottleneck, the decision, the tradeoff, the incident it prevents, and the outcome you can measure. You finish by defending a design out loud.
Built by Lakshya Kumar
Paste this into any AI chat. Fill in the bracketed parts with your context — you'll get back a straight answer on whether this belongs on your plate.
We grant free access case-by-case — students, career-switchers, builders on a tight budget. Sign in to send us a note.
Sign in to applyFinished the tasks? Take the prompt to your AI and get tested on it. We copy the prompt and open the app — just paste it in.
Design one, then break it six ways — the token maths never moves, but where the counter lives decides everything about how it fails.
Design the upload path, the two-store split and the CDN for a 26 PB file service, then break it six ways and see what actually survives.
Fan-out, channels, preferences and delivery state — plus the hardest promise in messaging: never send the same push twice.
Design a home timeline for 200M daily users, then break it six ways — hot keys, duplicate posts, and a ranker that dies mid-scroll.
Inverted indexes, the pipeline that fills them, and why 100x queries and 100x documents are two completely different emergencies.
Holds, TTLs and the one count that must not be eventually consistent — plus why locking the whole inventory is the fix you cannot afford.
Design a dual-rail UPI and card platform, then break it six ways — the double charge, the timed-out acquirer, a ledger that cannot lie.
Match riders to drivers whose positions change every second, then break it six ways — a ping firehose, a double-offered car, and dead maps.
Nine tenths of the work happens before the request exists. Getting that boundary right, and knowing what breaks at it, is the whole design.
Build the system that watches everything else, then break it six ways — including the one failure it is guaranteed to be present for.
The doc that gets read, the answer to why not X, the questions that find real problems, and ten designs turned into one artefact.
Complete all modules, then submit the required number of capstone projects. Each must earn a passing rating from an admin reviewer.
Pick a system this course did not cover — a chat app, a URL shortener, a food delivery tracker, a ticketing queue, anything with real users. Write the full design doc: requirements, capacity estimates with the arithmetic shown, a component diagram, the data model, and the API surface. Then take it through all six stress cases in order. For each one, state the bottleneck that breaks first, the decision you make, what that decision costs you, a concrete incident it prevents or causes, and the measurable outcome. Every stress case must also include an explicit paragraph on what does not change and why. A design that changes everything under every pressure has not been thought about.
I am working through the System Design course on Capstok, which designs ten systems and then breaks each one six ways: traffic becomes 100x, a region goes down, duplicates become unacceptable, reads must land under 100ms, data must stay in country, and a critical dependency turns unreliable. Here is my context: 1. A system I have worked on or use daily: [describe it in three sentences] 2. Its rough scale today: [users, requests/sec, data size — guess if you must] 3. The part I understand least: [e.g. "why we have a queue at all"] Given that, do four things: - Reconstruct that system as a one-page design: components, data flow, and where state lives. - Pick the ONE of the six pressures that system is least prepared for, and explain how it would fail — the specific bottleneck, not a general worry. - Name what would NOT need to change under that pressure, and why. Be specific; this is the part people get wrong. - Give me one measurement I could take this week that would tell me whether your analysis is right. Push back if my scale numbers look implausible.
Find a public engineering blog post describing a real production architecture. Reconstruct its design doc from what the post says, including the parts the authors left out. Then identify the three decisions you would have made differently and defend each one with the same six-part frame — bottleneck, decision, tradeoff, incident, outcome, and what stays the same. Be fair: for each disagreement, state the strongest case for the choice they actually made. The deliverable is a review a staff builder would take seriously, not a takedown.
Pick a published post-incident report — Cloudflare, GitHub, AWS, Slack and Atlassian all publish detailed ones. Reconstruct enough of the system to explain the failure, then answer the question the report usually does not: was this a bug to fix or a design to change? Produce the redesign, and be explicit about which of the six pressures the original design had never been tested against. Include what the redesign costs, because a design that only adds safety and never adds cost is not a real design.
Take any of the ten designs from this course and produce the plan to operate it in a country that requires personal data to stay inside its borders. Cover where every copy of the data rests — including caches, search indexes, content delivery edges, backups, logs and analytics, since those are where residency plans usually leak. Specify what functionality you lose, what it costs to run a second region, and how you would prove compliance to someone who does not trust you. State plainly which features you would switch off rather than ship non-compliant.
Take a system you actually work on or use, and write the plan for it handling a hundred times its current load. Show the current numbers and where you got them. Identify the order in which things break — not everything at once, but which limit is reached first, then what that exposes next. For each stage give the decision, the cost, and the point at which you would make it rather than doing it now. The most important section is the one listing what you would deliberately not change, and why premature work there would be waste.
Where the incident and outcome halves of the frame come from.