Scope#
A distributed system is several independent processes trying to preserve one useful service while messages are delayed, duplicated, reordered, or lost and while machines pause, restart, or disappear. These notes build the vocabulary and reasoning needed to follow one operation across those boundaries.
Read the notes in order. The sequence begins with the system model and an ordinary remote call, then adds time, failure detection, group communication, consensus, partitioned storage, replication, distributed computation, shared data abstractions, security, and incident analysis. Each mechanism is introduced through the problem that requires it, the assumptions under which it works, and the evidence an operator would inspect when it fails.
The primary lecture source is the University of Illinois CS 425 / ECE 428 Fall 2025 course. Historical systems such as Napster, Chord, MapReduce, Storm, and the original Dynamo remain useful because their mechanisms recur in current systems. Product-specific claims are checked against current project documentation before they are presented as current behavior.
Learning path#
| Note | Question answered | What it supplies to the next stage |
|---|---|---|
| DS1 | What changes when a call crosses a process? | RPC uncertainty, operation identity, deadlines, and retry budgets |
| DS2 | How can events be ordered without one global present? | Physical-time bounds, causality, logical clocks, and consistent cuts |
| DS3 | What can silence prove? | Suspicion, membership, dissemination, and incarnation |
| DS4 | How can a group deliver in order and keep stale holders out? | Multicast order, election assumptions, leases, and fencing |
| DS5 | How can one durable authority survive crashes? | Consensus, replicated logs, state machines, and etcd |
| DS6 | How are records placed, routed, and repaired? | Partitioning, distributed hash tables, and Cassandra as a concrete case |
| DS7 | What may clients observe across copies and transactions? | Consistency models, session rules, replication, and atomic commit |
| DS8 | How does computation move through a cluster? | Shuffle, stream state, checkpoints, placement, and resource policy |
| DS9 | What do local-looking shared abstractions hide? | Filesystem, memory, and edge failure contracts |
| DS10 | How is the complete service protected, investigated, and rebuilt? | Security, incident analysis, and recovery |
Difficulty labels describe the depth inside a note, not another reading order. Follow the note numbers; DS6 and DS8 apply mechanisms introduced in earlier Advanced notes.
Source map#
| Supplied lecture material | Used principally in |
|---|---|
| L1: introduction and L2-3: cloud computing | DS1 system model and failure boundaries |
| L4: MapReduce and Hadoop | DS8 distributed dataflow |
| L5: gossip and L6: failure detection and membership | DS3 membership and failure detection |
| L7-8: peer-to-peer systems | DS6 partitioning and distributed hash tables |
| L9-11: key-value and NoSQL stores | DS6 partitioning and DS7 replication |
| L12: time and ordering | DS2 clocks, causality, and snapshots |
| L16: multicast, L17: leader election, and L18: mutual exclusion | DS4 group communication and coordination |
| L19-20: RPCs and concurrency control and L21: replication control | DS1 RPCs and DS7 transactions and replication |
| L22: network structure, L22B: stream processing, and L23: scheduling | DS8 network structure, dataflow, and scheduling |
| L24A: distributed file systems, L24B: consistency models, and L25A: distributed shared memory | DS7 consistency and DS9 shared data abstractions |
| L25B: sensor networks and L26: graph processing and machine learning | DS8 parallel computation and DS9 edge systems |
| L27: security and L28: datacenter disasters | DS10 security and incident analysis |
| Final review | The complete dependency map and worked case |
The supplied set jumps from L12 to L16. DS5 therefore uses the final review's consensus topic together with the original Paxos and Raft papers; it does not imply that the missing lecture decks were reviewed.
Useful background#
- Comfort reading an HTTP request and a small database transaction
- Basic familiarity with processes, files, IP addresses, and persistent storage
- Willingness to write down assumptions about failures and timing before choosing an algorithm
For a slower introduction to machines, networks, and storage, start with low-level infrastructure. For cloud service boundaries and Kubernetes, use cloud infrastructure. The system design module applies these mechanisms to interview and production design decisions.