Metadata Card
- Prerequisites: Vol 4 Networking (TCP/IP, HTTP), Vol 5 Database (Transactions, ACID)
- Estimated Time: 45 minutes
- Core Difficulty: Intermediate
- Reading Mode: High focus
- Completion Milestone: List the 8 Fallacies of Distributed Computing, explain the CAP trade-off, understand the core implication of FLP impossibility, distinguish logical from physical clock use cases
Your Progress
After leaving the City of Artisans, you and a fully equipped team of engineers are deployed to the Expeditionary Army front line. Here, you discover that single-machine weapons — a sword and shield — are completely inadequate on the cluster battlefield.
General Lin stands before a battle map, pointing at a transmission line: "Networks can fail, machines can crash, messages may arrive late. You need to learn to fight in this environment."
From today, your battlefield is not a single-core CPU and one hard drive — it's a group of uncertain, unreliable, failure-prone machines. You need to build reliable services on top of them.
Your Task
Understand why distributed systems are orders of magnitude harder than single-machine systems. It's not that the code is more complex — it's that your fundamental assumptions have changed: the network is not reliable, clocks are not trustworthy, partial failure is not an exception, it's the norm.
Fallacies of Distributed Computing
Eight false assumptions from 1994:
- The network is reliable
- Latency is zero
- Bandwidth is infinite
- The network is secure
- Topology doesn't change
- There is one administrator
- Transport cost is zero
- The network is homogeneous
CAP Theorem
When a network partition occurs, you choose between Consistency and Availability. P is not optional — partitions happen.
CP (Consistency preferred): stop accepting writes during partition. AP (Availability preferred): nodes continue independently, accept temporary inconsistency.
FLP Impossibility
In an asynchronous distributed system where one process may crash, no deterministic algorithm can guarantee consensus in finite time. Real systems use timeouts and leader election (partially synchronous models) to circumvent this.
Clocks & Time
Physical clocks drift. Lamport Clock: monotonic integer counter, provides happened-before ordering. Vector Clock: each node maintains a vector, can detect concurrent events.
Common Pitfalls: Treating CAP as a 24/7 design principle, treating eventual consistency as "don't need to handle," relying on physical timestamps for causal judgment, believing FLP means "distributed systems are hopeless."
Traveler's Notes
The fundamental difficulty of distributed systems isn't writing multi-threaded code — it's that all your determinism assumptions collapse when facing partial failure, unreliable clocks, and network partitions. CAP tells you the trade-off, FLP tells you the theoretical floor, and clocks tell you not to trust "time."
Next: RPC & Serialization.