// the one-minute version
A distributed system is many independent computers cooperating over a network to look like one system. They communicate via protocols (notably TCP/IP), often through remote procedure calls that make a network request look like a local function call. The hard part isn't talking — it's coping with partial failure: one machine can die while the rest keep running, and you must handle it. Consensus algorithms get machines to agree despite failures.
Everything so far assumed one computer. But Google, your bank, and the web itself are thousands of machines working together. Making many computers behave like one sounds like more of the same — it isn't. The network changes the rules in deep ways.
01 What and why
A distributed system is a collection of separate computers, each with its own memory and clock, that coordinate over a network. The payoffs: resource sharing (use data and devices across machines), speedup (split work across many computers), reliability (if one machine fails, others continue), and scalability (add machines to grow).
02 Network structure and protocols
Machines connect over a LAN (local, one building) or WAN (wide, across the world — the internet). They speak layered protocols: IP routes packets between machines, TCP adds reliable, ordered delivery on top (retransmitting lost packets), UDP offers fast unreliable delivery, and applications layer their own protocols (HTTP, etc.) above. Each layer hides the one below — the same abstraction discipline as the rest of the book.
03 Communication: messages and RPC
At bottom, distributed machines exchange messages. But raw message-passing is tedious, so the dominant abstraction is the remote procedure call (RPC): you call what looks like an ordinary function, and underneath the system packages the arguments (marshalling), sends them across the network, runs the procedure on the remote machine, and ships the result back. A stub on each side hides the messaging.
04 Distributed file systems
A distributed file system (DFS) lets clients access files on remote servers as if local (NFS, Chapter 15). It must handle naming (a consistent way to refer to files across machines), caching (keep copies on clients for speed), and consistency (when one client changes a file, others must eventually see it) — the same cache-staleness problem from Chapter 1, now across a network.
05 The defining problem: partial failure
On one machine, a crash takes everything down together — simple. In a distributed system, part fails while the rest runs, and often you can't tell whether a silent machine has crashed or is just slow. This ambiguity is the core difficulty of the whole field.
06 Coordination and consensus
With no shared clock or memory, machines need protocols to agree. Logical clocks order events without a shared time source. Consensus algorithms (Paxos, Raft) get a group of machines to agree on a value even when some fail or messages are lost — the backbone of reliable distributed databases, leader election, and coordination services. The famous CAP theorem frames the trade-off: under a network partition you can't have both perfect consistency and availability.
07 Naming
Resources spread across machines need consistent names. A naming system like DNS (which maps example.com to an IP address) translates human-friendly names to network locations and hides the fact that the underlying machine might move or be replaced — letting services scale and fail over invisibly.
common catches & gotchas
- A remote call is not a local call — RPC hides the network, but the call is far slower and can fail. Code assuming local-call reliability breaks under real conditions.
- You can't distinguish slow from dead — A silent machine might be crashed or just lagging. Timeouts guess; they're never certain. Whole protocols exist to cope with this.
- Exactly-once is hard — After a failed RPC you may not know if it ran. Retrying risks doing it twice; not retrying risks zero times. Idempotency and dedup exist for this.
- Clocks aren't synchronized — Separate machines have separate, drifting clocks. Don't order distributed events by wall-clock time — use logical clocks.
- CAP trade-off is real — Under a partition you choose consistency or availability, not both. Pretending otherwise causes subtle data bugs.
08 Questions students actually ask
What makes distributed systems fundamentally harder than single machines?
Partial failure: one machine can fail while others keep running, and you often can't tell whether a non-responding machine has crashed or is just slow. There's no shared clock or memory, so coordination needs explicit protocols.
What does RPC do for you?
It makes a call to code on another machine look like an ordinary local function call — marshalling the arguments, sending them over the network, running the procedure remotely, and returning the result, hiding the messaging details.
Why is treating RPC like a local call dangerous?
Because a remote call can be vastly slower and can fail outright (network drops, remote crash), and after a timeout you may not know if it ran. Code assuming local-call speed and reliability breaks badly under real network conditions.
What is consensus and why does it matter?
Consensus is getting a group of machines to agree on a value even when some fail or messages are lost. Algorithms like Paxos and Raft provide it, underpinning reliable distributed databases, leader election, and coordination services.
Why can't distributed machines just use timestamps to order events?
Their clocks are separate and drift apart, so wall-clock times disagree. Logical clocks order events by causality instead of physical time, which is what distributed algorithms rely on.
09 Key takeaways
- A distributed system makes many networked computers act as one.
- Benefits: resource sharing, speedup, reliability, scalability.
- They communicate via layered protocols (IP, TCP/UDP) and often RPC.
- RPC hides messaging but a remote call is slow and can fail — never treat it as local.
- Partial failure — part down, rest up, can't tell which — is the defining difficulty.
- Consensus (Paxos/Raft), logical clocks, and naming systems (DNS) make coordination reliable.
10 Wrapping up
That's the distributed world in outline. The book closes with two grand case studies that tie every concept together in real, shipping systems — first the one that runs most of the world's servers. Next up: The Linux System.