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.

One machine has an update
a new piece of data needs to exist everywhere it matters
Communication carries it over the network
no shared memory — every coordination step is an explicit message
Replication copies it to other machines
for speed and for survival if one machine goes down
Consistency
handling the window where copies briefly disagree
Consensus
every reachable machine agrees on the same answer
Fault tolerance: it keeps working anyway
even while individual machines fail, restart, or vanish
Replication: This Article, on Two Servers Not a hypothetical — this is how this exact page was published Database server A holds a full copy of this article verified independently Database server B holds a full copy of this article verified independently same content, same byte count if server A goes offline, server B still answers requests — this is fault tolerance working exactly as intended the tradeoff: every publish now has to succeed on both servers, or an inconsistency opens up between what each one is serving which is exactly why each insert here is checked independently
Consensus: Agreeing Despite One Failure A majority of reachable machines can still agree on one answer Node 1 says: value X Node 2 says: value X Node 3 unreachable 2 out of 3 is still a majority the group can safely agree on value X and keep going without waiting for node 3 to come back this is the core idea behind Paxos and Raft, just without the full protocol detail the hard part is handling every possible timing of failures, not just this one

Take distributed systems further

Ask the copilot about this term, or have our engineers assess it against your process.