Learn
Three tracks, each gated in order. Finish a lesson, pass its checks, and the matching lab opens. Finish every lesson and lab in a track and you can claim a certificate.
FoundationFree — sign in
Name the pieces. Walk the request.
The spine. One component at a time, then four complete systems. Free once you have an account — progress still unlocks in order.
0/20 lessons · 0/12 labs0%
Free — create an account to keep progress.
Foundations
How a request travels, and why speed, load, and failure are different problems.
- Client vs serverA client asks. A server answers. The same machine is often both at once, and which one it is depends entirely on which way the request is pointing.~6 min
- Request and responseA request carries intent, a response carries a result or an error, and every architecture diagram you will ever draw is a request path with the timing left out.Sign in
- Latency vs throughputLatency is how long one person waits. Throughput is how many people you finish per second. Improving one can leave the other exactly where it was.Sign in
- Availability vs consistencyAvailability means you get an answer. Consistency means the answer agrees with everyone else's. Keep a second copy of your data and you will eventually have to choose which one you would rather break.Sign in
- Why we scaleYou scale because something specific ran out — CPU, memory, disk, connections — or because one machine failing is not an outage you can afford. Anything else is decoration.Sign in
Building blocks
One component at a time: what it is, when to use it, and what it cannot do.
- App serverThe app server is where your logic runs. Its most valuable property is that it holds nothing worth keeping, which is exactly what lets you throw a second one at the problem.Sign in
- Load balancerA load balancer is the one address clients know. Behind it, instances can be added, replaced and quietly removed while they are failing, and nobody outside notices.Sign in
- DatabaseThe database is the one component holding the only copy of the truth. That is why it is usually the first thing to run out of room, and the last thing you can afford to lose.Sign in
- CacheA cache is a fast, incomplete, slightly-out-of-date copy of something expensive. It is the highest-leverage component you can add, and the easiest one to make quietly wrong.Sign in
- CDNA CDN is a cache with geography. Your servers are in one place, your users are everywhere, and the speed of light charges for the difference.Sign in
- Object storageFiles go in a bucket. The database keeps a short string pointing at them. Mixing those up is one of the few beginner mistakes that gets worse every single day it survives.Sign in
- Message queueA queue lets a request record what should happen and return, while the slow part happens after the user has gone. It buys time, and it does not buy capacity.Sign in
Numbers
Order-of-magnitude estimates so you can justify a cache — not a spreadsheet course.
Patterns
Recurring shapes: read-heavy vs write-heavy, fan-out, retries, and idempotency.
- Read-heavy vs write-heavyCopies help reads and cost writes. Before reaching for a cache or a replica, find out which way your traffic actually runs — and whether anything repeats.Sign in
- Fan-out on write vs readOne post, many readers. You can do the work when it is written or when it is read, and the right answer flips depending on a single number: how many people are on the other end.Sign in
- Retries and idempotencyA timeout does not mean the work did not happen. It means you did not hear back — and the only safe way to retry is to make doing it twice mean the same as doing it once.Sign in
First systems
Four complete designs. Depth over a catalog of interview logos.
- URL shortenerThe first complete system, and a gift of a first one: the read path and the write path are wildly different sizes, and every component you add has to justify itself against a number.Sign in
- Pastebin and file uploadAlmost the same system as the shortener, with one difference that changes everything: the thing being stored is no longer a short string, and might be fifty megabytes.Sign in
- Rate limiterA counter per caller, in a store fast enough to check on every request, placed early enough that rejecting costs almost nothing.Sign in
- Simple group chatChat has a reputation as the hard one. For a group of six it is a table of messages, an index, and a queue for the notifications — and every piece is something you already have.Sign in
PractitionerBy request
Things fail. Design for it.
What the spine leaves out: timeouts, hot keys, sharding, and work that happens after the response. Labs stop telling you which box is missing.
0/23 lessons · 0/18 labs0%
Ask for access — free →
Staying up
Timeouts, retries that do not stampede, shedding load before it takes the floor out, and knowing when to stop calling at all.
- Timeouts and deadlinesA call with no timeout is a promise to wait forever. Deadlines turn one slow dependency into a fast error instead of a queue that eats the whole app tier.Locked
- Retries that do not stampedeA naive retry multiplies load exactly when the system can least afford it. Backoff, jitter, and a retry budget keep a hiccup from becoming an outage.Locked
- Shedding load on purposeWhen demand exceeds capacity, something must be refused. Choosing what to drop is design; letting the queue decide is an outage.Locked
- Breakers and bulkheadsShedding load protects you from your callers. A breaker protects you from the thing you call: it watches the failure rate, stops calling, and fails instantly until the dependency proves it is back.Locked
- Knowing before the customer doesTimeouts, breakers and shedding all need a number to fire on, and that number has to come from somewhere. Metrics say what is happening, traces say where, logs say why — and the average hides all three.Locked
- Shipping without taking it downMost outages are not caused by traffic. They are caused by the last deploy. Ship to a small slice first, watch the signals you built in the previous lesson, and keep the way back cheap.Locked
Data at scale
Indexes, hot keys, caches that expire together, and splitting one database into many without moving everything.
- Indexes and access pathsAn index is a second copy of your data organised for one question. It makes that question fast and every write slightly slower.Locked
- Page 5,000 is where OFFSET diesLIMIT 20 OFFSET 100000 asks the database to find a hundred thousand rows and throw them away. Keying off the last row you saw turns every page into the same cheap index lookup.Locked
- You just wrote it. Why is it not there?A read replica is a copy that is always slightly behind. Send reads there and the write path gets cheaper — right up until a user saves something and the next screen tells them it does not exist.Locked
- The database runs out of connections firstA database connection is not free — it is memory and a process. Fifty app servers holding a hundred connections each is five thousand, and Postgres fell over somewhere around a few hundred.Locked
- Invalidation, TTLs, and the stampedeA cache is only fast while it hits. The dangerous moment is the miss — one popular key expires and every request that wanted it goes to the database in the same instant.Locked
- Hot keys and uneven loadAverages hide the problem. One celebrity row, one trending code, one popular shard can saturate a single machine while the rest of the fleet idles.Locked
- Adding a node without moving everythingPlacing keys with hash mod N is fine until N changes. Adding one node reshuffles almost every key, and the moment you need capacity is the worst possible moment for a cold cache.Locked
- Splitting one database into manySharding buys write capacity by giving up the things one machine made easy: joins, transactions, and uniqueness across the whole dataset.Locked
- Changing a schema with traffic on itYou cannot stop the world to rename a column. Expand, migrate, contract: add the new shape, write both, backfill, move reads, and only then delete the old one.Locked
Work after the response
Streams, workers, delivery guarantees you can actually defend, and what to do with the message that will never succeed.
- Streams instead of queuesA queue hands each job to one worker and forgets it. A stream is an ordered log many consumers read independently, and can re-read.Locked
- At-least-once and the outboxExactly-once delivery does not exist across a network. You get at-least-once plus idempotent consumers, which is the same thing where it counts.Locked
- When the queue never drainsA queue absorbs a spike. It does not add capacity. If arrivals beat departures for long enough the buffer is simply where the latency is hiding — and one message that can never succeed will recycle forever.Locked
Systems that bend
Four designs where the naive answer falls over on the second question.
- Sessions, tokens, and logging everyone outLooking a session up in the database on every request makes auth the busiest query you own. Signing a token removes the lookup, and removes your ability to take the token back — until you design for that.Locked
- A news feed that loads fastFeeds are the canonical fan-out problem. Precompute for ordinary users, query on read for celebrities, and merge the two at request time.Locked
- Notifications without a thundering herdSending a million pushes is easy. Sending them without melting your own API when everyone taps at once is the actual design.Locked
- Matching riders and driversA geospatial matching problem with constant writes, a strong locality bias, and a hard requirement that two riders never get the same driver.Locked
- Two people, one seatInventory that is checked and then bought minutes later needs a third state between free and sold: held. The hard part is not taking the seat — it is giving it back when the buyer walks away.Locked
ArchitectBy request
Many machines, one answer.
Consensus, multi-region, and ledgers that must never lose a rupee. The hardest labs here start from an empty canvas and have more than one defensible answer.
0/9 lessons · 0/6 labs0%
Ask for access — free →
Agreeing at a distance
Quorums, clocks, and why two machines cannot both be certain at the same instant.
- Quorums: how many copies must agreeWith N copies, requiring W writers and R readers such that R + W > N guarantees any read sees the latest write. Everything else is a knob.Locked
- Leaders, elections, and split brainConsensus is how a group of machines agrees on one value despite failures. Its main product is a single leader that everyone accepts.Locked
- Clocks lie, so order things yourselfWall-clock timestamps from different machines cannot be compared safely. Logical clocks order events by causality instead of by time.Locked
Across regions
Cells, multi-region writes, and blast radius as a design input.
- Writing in more than one regionReads replicate globally without much drama. Writes are where geography charges you the speed of light.Locked
- Cells and blast radiusSplit the system into independent cells so a failure takes down a slice of users instead of all of them.Locked
- Separate the write model from the read modelThe shape that makes writes correct is rarely the shape that makes reads fast. Store the write model, then derive read models from it.Locked
Systems that must not lose
A ledger, a search tier, and a global timeline. No starting graph, no single right answer.
- A ledger that cannot lose moneyMoney is the case where eventual consistency is not an acceptable answer. Append-only entries, strict idempotency, and balances derived rather than stored.Locked
- Search over everythingA search tier is a derived, sharded, replicated read model with its own failure modes and a permanent freshness-versus-cost tension.Locked
- A timeline for the whole planetEverything from the course at once: fan-out, hot keys, regional writes, cells, and a read path that must stay under a hundred milliseconds.Locked
52 lessons across three tracks. Everything in Foundation is free with an account.