Revision · Distributed Systems Theory

This part named the permanent terrain of distributed systems: the network is unreliable, there is no global “now,” and parts fail independently and partially. Every page pulls the same thread — what does this buy us, and what does it cost? — because you cannot have perfect consistency, constant availability, and partition immunity all at once.

What this part covered

• Partial failure and network ambiguity — a timeout is a guess, not a fact: “never arrived,” “ran but the reply was lost,” and “still in flight” look identical, which forces retries, which create duplicates.
• CAP & PACELC — under a partition you must choose consistency or availability; PACELC adds the trade-off CAP forgets — even when the network is healthy, you trade latency against consistency.
• Consistency models — a spectrum, not a binary: linearizable, sequential, causal, and eventual, with practical session guarantees like read-your-writes sitting in the middle; stronger models cost latency and availability.
• Consensus: Raft & Paxos — how independent nodes agree despite failures using quorums and an elected leader, powering etcd and ZooKeeper — bought with the cost of coordination round-trips.
• Time, clocks & ordering — wall clocks drift and NTP only narrows the lie, so order must be constructed with happens-before and Lamport timestamps, and concurrency detected with vector clocks.
• Idempotency — the discipline that turns the duplicates the network forces on you from a bug source into a non-event, via idempotency keys and deduplication in message systems.
• Leader election & coordination — electing one node to act, then guarding against split-brain with fencing tokens and coordination services so two nodes never both believe they are in charge.

The takeaway

Distribution buys fault tolerance, scale, and low latency, but it demands payment in consistency, availability, and coordination cost — and strengthening one guarantee almost always weakens another. The art is choosing where to spend, deliberately and per workload. Carry these questions into design: what does it assume about the network, where does it spend its consistency budget, and what happens the moment a partition cuts the cluster in half? The next part applies this lens to scaling, where these same limits cap how fast you can grow.