Stage 2

Data & consistency at scale

Replication, CAP/PACELC, consistency models, quorums, conflicts.

1. CAP, PACELC, and what consistency actually costs

   The most-quoted and most-misunderstood result in distributed systems. CAP does not say 'pick two of three' — it says something far narrower and far more useful: when the network partitions, you must choose between staying consistent and staying available, and you cannot have both. This lesson states the theorem correctly, kills the 'two of three' meme, extends it with PACELC (the part that matters on the 99.9% of days there is no partition — the everyday trade of latency against consistency), and shows why a single-node system like Fable's sidesteps the whole thing by not being distributed at all.

   13 min
2. Consistency models: from linearizable to eventual

   'Eventually consistent' and 'strongly consistent' are the two words everyone knows and the two ends of a whole spectrum nobody teaches. In between sit the models that actually solve real bugs: causal consistency, and the session guarantees (read-your-writes, monotonic reads) that make an eventually-consistent system feel correct to a single user. This lesson lays the spectrum out from strongest to weakest, says exactly what each model promises and forbids, ties each to the coordination cost that buys it, and shows how the read-your-writes bug from the replication lesson is really a missing session guarantee.

   14 min
3. Replication topologies & quorums

   The databases track showed how one primary streams to replicas. This lesson is about the shapes above that: single-leader, multi-leader, and leaderless replication, and the trade each makes. It then works through the quorum arithmetic that leaderless systems (Dynamo, Cassandra) run on — the R + W > N rule that lets you dial consistency against availability with two numbers — including why it's a probabilistic promise, not the linearizable guarantee people assume, and how sloppy quorums and hinted handoff bend it further for availability.

   14 min
4. Conflict resolution & distributed transactions

   Once more than one node can accept a write, two of them can change the same thing at once — and something has to decide what the truth becomes. This lesson covers how concurrent writes are even detected (why wall-clock timestamps lie, and what version vectors do instead), the resolution strategies from the data-losing simplicity of last-write-wins up to the mathematical guarantees of CRDTs, and then the other half of the problem: making one operation atomic across several nodes. Why two-phase commit is correct but blocking and avoided at scale, and why sagas trade atomicity for availability with compensating actions.

   15 min