Distributed Systems
Distributed systems take the previous topic's race conditions and coordination problems and stretch them across many separate machines connected by nothing but the network the computer-networks topic already covered, and this series' own publishing process is a live example running the moment this very sentence loads. Communication between machines works nothing like the threads from the concurrency topic, which could simply share memory directly: separate machines have no shared memory at all, so every bit of coordination has to travel as an explicit message over the network, carrying its own delay and its own chance of arriving late, out of order, or not at all. Replication keeps a copy of the same data on more than one machine on purpose, trading extra storage for two real benefits: a nearby copy can usually be read faster than a far-away one, and if one machine becomes unreachable the others still hold the data — this very article, in fact, was published as an identical copy stored on two completely separate database servers specifically so that neither server failing takes the content down. Consistency is what makes replication hard: if the same piece of data lives in two places and gets updated, there's an unavoidable window where one copy reflects the update and the other doesn't yet, which is the exact same lost-update danger the concurrency topic's race conditions described, except now the delay between the two copies noticing each other is network latency instead of a few nanoseconds on one chip. Consensus is how a group of machines agrees on a single shared answer — which update actually happened first, which machine is currently in charge — even when some machines are slow, unreachable, or have failed outright; real consensus protocols like Paxos and Raft solve this formally, but the underlying goal is simple: get every honest, reachable machine to agree on the same answer, and never let the group settle on two different answers at once. Fault tolerance is the payoff of doing replication and consensus correctly: a distributed system built on these ideas keeps serving correct results even while individual machines fail, restart, or temporarily disappear, which is exactly why this series' own deploy process verifies an insert on each database server independently rather than trusting that success on one server guarantees success on the other. None of this complexity exists in a single-machine program; it is the direct cost of wanting a system to survive hardware failure, serve users from anywhere, or simply handle more traffic than one machine ever could — and the next topic, computer security, is what has to be added once those many communicating, trusting machines become something an attacker can also reach.