Learn to design systems where the network is unreliable, data lives on several nodes, and failure is part of normal operation.
A proposed six-month syllabus. Dates, the timetable, and grading rules will be confirmed before launch.
How MIT, Cambridge, UW, Yandex SDA, ITMO, and CMU structure their courses, what their labs teach, and which ideas could strengthen our syllabus.
Read the course comparisonTwo lectures per month for the first five months, with practice between sessions. Month six is for integration, experiments, and the final project defense.
Failures and time
Lectures 01–02
Networks and replicas
Lectures 03–04 · lab 01
Consensus and data
Lectures 05–06 · lab 02
Transactions and events
Lectures 07–08 · lab 03
Testing and architecture
Lectures 09–10
Experiments and defense
Lab 04 · final project
Each topic starts with an engineering question and leads to a concrete outcome. Expand a lecture to open its slides, worked example, and exercise.
Failure models, network latency, partial failures, and invariants.
After the lecture: Define what a service must preserve when a node fails.
Physical and logical clocks, causality, Lamport clocks, and vector clocks.
After the lecture: Reconstruct causal order from the logs of several nodes.
RPC, timeouts, retries, idempotency, and backpressure.
After the lecture: Design an API that handles lost responses and duplicate delivery.
Leaders and replicas, quorums, consistency models, CAP, and PACELC.
After the lecture: Explain the trade-offs between availability, latency, and consistency.
Raft, leader election, replicated logs, and fault-tolerance limits.
After the lecture: Trace a leader change and the minority partition during a network split.
Sharding, key selection, consistent hashing, hot keys, and rebalancing.
After the lecture: Choose a partitioning scheme and identify its bottlenecks.
Isolation, two-phase commit, sagas, compensations, and the outbox pattern.
After the lecture: Preserve a business invariant without a shared cross-service transaction.
Message ordering, delivery guarantees, deduplication, and log replay.
After the lecture: Design a consumer that safely processes redelivered events.
SLIs/SLOs, tracing, load experiments, fault injection, and recovery.
After the lecture: Test invariants and measure recovery after a failure.
Putting a system together: requirements, latency budgets, constraints, and reliability costs.
After the lecture: Defend a service architecture with measurements and explicit trade-offs.
Build a distributed task service: an API accepts requests, storage preserves state, and a queue dispatches work to workers. Each lab adds a new layer and a failure scenario.
Build a task-service API. Add timeouts, retries, and idempotency keys. Simulate a lost response.
A repeated request creates no duplicate task; a test reproduces the lost response.
What to submit: API + failure tests
Lab guide and setupAdd replicated storage using an existing consensus implementation. Stop the leader and partition the network.
Record read/write availability, durability of acknowledged data, and recovery time.
What to submit: Cluster + experiment report
Lab guide and setupAdd a queue and task workers. Implement an outbox and deduplication; test a crash between saving a result and acknowledging a message.
Redelivery creates no duplicate business effect; unfinished work resumes after a restart.
What to submit: Workers + invariant checks
Lab guide and setupIntegrate the service and add metrics and tracing. Run a load experiment and a failure scenario, then defend your design.
A reproducible setup, measured latency and recovery, and documented system limitations.
What to submit: Service + report + defense
Lab guide and setupBy the end of the course, students will have a working service and experiments that demonstrate its guarantees and limitations.
Students who can already build applications and want to understand what changes when a single process becomes a system of several nodes.
One programming language, HTTP and database basics, Git, and basic container skills. No prior distributed systems experience is required.