Interactive course · 6 lessons · ~2 hours

Distributed systems,
or: the network is not fine

A distributed system is several computers pretending to be one — over a network that drops messages, clocks that lie, and machines that die mid-sentence. This course is the field's core ideas as things you can operate: lose the messenger, skew the clocks, crash the coordinator, melt a service with your own retries, and learn exactly which guarantees survive.

01

The unreliable network: where all the trouble starts

Prove the Two Generals problem to yourself by losing messengers, then face the question that defines the field: your payment request timed out — was it processed? Retry naively and double-charge a customer; fix it with idempotency.

two generalstimeout ambiguityat-least-onceidempotency keys
02

Time & ordering: your clocks are lying to you

Skew two server clocks and watch a reply get timestamped before the message it answers. Then build the fixes by hand: Lamport clocks for order, vector clocks for detecting what actually happened concurrently.

clock skewhappened-beforeLamport clocksvector clocks
03

Partitioning: splitting data without tears

One machine can't hold everything. Shard with mod-N and watch adding one node reshuffle nearly every key; switch to consistent hashing and move almost none. Then create a celebrity hotspot and fix it with key salting.

hash vs rangeconsistent hashingrebalancinghotspots
04

Distributed transactions: atomic across machines

Run two-phase commit's happy path, then crash the coordinator at the worst instant and meet the in-doubt participant holding locks nobody can release. Then trade atomicity for availability with a saga — and watch its compensations leak.

2PCin-doubt & blockingsagascompensation
05

Consistency models & CAP: what reads are allowed to say

Play referee: given a history of reads and writes, is it linearizable? Then take a live partition and make the CAP choice yourself — reject writes or accept divergence — and see why the real trade-off (PACELC) is paid even on sunny days.

linearizabilityeventual consistencyCAPPACELC
06

Resilience: how systems eat themselves, and how to stop it

Slow one dependency and watch well-meaning retries triple the load and melt it — a self-inflicted outage. Then install the defenses: jittered backoff, a circuit breaker you operate through its three states, and load shedding.

retry stormsbackoff + jittercircuit breakersload shedding
messages / requests delivered / healthy lost / failed / violated

This course pairs with the Database Replication course: replication architectures, quorums, and Raft consensus live there and are referenced here rather than repeated. The two together cover most of what "distributed systems" means in practice — this one supplies the network, time, partitioning, transaction, and resilience layers.