Most courses teach you to call Redis and SQS. This one has you write the ring, the visibility timeout and the rolling hash yourself.
You can wire up Redis, publish to a queue and sync a folder without ever knowing what any of them do. That works right up until the moment it does not — a hot key melts one cache node, a consumer takes longer than the visibility timeout and every message is processed twice, a sync loop starts echoing against itself. At that point the documentation stops helping, because the thing you need to understand is the mechanism underneath. This course builds twelve of those mechanisms. A realtime chat with ordering that survives multiple devices. A presence system where the green dot is a graph problem. A gateway holding a million open sockets. Snowflake identifiers, including the worker-assignment part every tutorial skips. A cache cluster with its own hash ring and failure detector. A key-value store on plain SQL, and the honest account of where it stops working. A message broker with real visibility timeouts. A scheduler firing a hundred million timers. Flash-sale admission control. Search history and hashtag pipelines. Live commentary fanning out to millions. And the rsync algorithm, rolling hash and all. You write each one, then break it.
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.
Green dots, typing bubbles and blue ticks make nineteen writes per message, and nearly all of them must be forgotten within seconds.
A request tier and a connection tier are different machines: count the bytes, hold the sockets, survive the storm your own deploy causes.
Auto-increment stops at one database. Pack a millisecond, a worker number and a counter into 64 bits and hand out four thousand every tick.
A ring you measured rather than assumed, gossip membership, real eviction, and the origin-load bill that a single dead node hands you.
Build the table, the expiry and the atomic operations yourself, then learn the exact numbers at which a specialist store earns its keep.
Visibility timeouts, in-flight tables, long-poll receive and redrive — the mechanisms a queue hides behind four API calls.
Cron runs a handful of jobs on a clock. Holding a hundred million one-shot user timers is a different system: wheels, buckets, leases.
Two hundred thousand buyers, five thousand units, seventeen seconds — and almost all the design work happens before the clock starts.
Search history and hashtags are mostly policy: what to record, what to delete, and what one viral tag does to a single database key.
The cheapest hard problem here, once you notice every reader gets identical bytes — so the CDN fans out and your origin barely moves.
Two machines, one 2 GB file, a few kilobytes different — and a protocol that finds the difference without either side reading the other.
Complete all modules, then submit the required number of capstone projects. Each must earn a passing rating from an admin reviewer.
Pick any one system from this course and implement it properly in a language of your choice — not a toy, a thing with tests. It must handle the failure case the module identified as its hardest: the cache ring must rebalance without losing more keys than the maths predicts, the broker must redeliver after a lease expires, the sync must resume a transfer killed halfway. Ship a README that states the guarantee you provide and, just as importantly, the one you deliberately do not. Include the benchmark that demonstrates the property, with the command to reproduce it.
I am working through the System Design by Building course on Capstok, which implements twelve systems from scratch: realtime chat, presence, a connection tier, ID generators, a distributed cache, a KV store on SQL, a message broker, a task scheduler, flash-sale admission, text pipelines, live commentary fan-out, and file sync. Here is my context: 1. A managed service I use without really knowing how it works: [name it] 2. What I currently believe it does internally: [your honest guess, however rough] 3. My strongest language: [language] Given that, do four things: - Tell me which of the twelve modules explains that service's core mechanism, and what specifically I would learn there. - Correct the part of my guess that is wrong, and be direct about it rather than diplomatic. - Give me the smallest program in my language that demonstrates the mechanism — under 60 lines, runnable, no dependencies. - Name one failure mode of that service that I would only anticipate if I understood the internals.
Take a managed service your project depends on — a hosted cache, queue, scheduler or search index — and write the design for running the equivalent yourself. Be rigorous about the comparison: what the managed version does that your design does not, what it costs in both money and operational attention, and the scale at which each answer flips. Give figures in both rupees and dollars. The conclusion is allowed to be, and often should be, keep paying for it — but you must have earned that conclusion rather than assumed it.
Choose a real open-source implementation of any primitive from this course — Redis cluster's slot migration, NSQ or RabbitMQ's delivery path, Quartz or Temporal's timer storage, librsync, Dragonfly's eviction. Read enough of it to explain three decisions its authors made that differ from the design in this course, and why they were right to make them. This is the skill that separates someone who has read about a system from someone who can work on one.
Pick one failure this course describes — duplicate delivery after a lease overrun, a cold cache stampede after failover, an ID collision from a duplicated worker identifier, the sync echo loop — and build the smallest possible harness that reproduces it reliably. Then fix it and show the same harness passing. The deliverable is the harness, both runs, and a short account of why the naive version was wrong in a way that would not have shown up in ordinary testing.
Pick something with a real mechanism at its heart that this course skipped — a URL shortener's key space, a leaderboard, a geofence service, a collaborative text editor, a feature-flag evaluator at the edge. Produce the module that would belong in this course: the problem, the core design, the key data structure implemented, the two or three genuinely hard sub-problems, and a closing section on the one or two pressures that actually bite it. Teaching it is the test of whether you understand it.
The original identifier design the whole industry copied.