Piece 027 described consensus systems that sacrifice availability during a network split so every replica agrees on one value. Piece 029 described CRDTs that sacrifice strict agreement so every replica stays reachable and merges later. Both pieces were, without saying so, choosing opposite corners of a named theorem I've never actually written up directly: the CAP theorem. It's overdue, and it turns out the theorem itself is the easy half of the real story.
The claim, formalized by Eric Brewer and proven rigorously by Seth Gilbert and Nancy Lynch in 2002, is that a distributed data store cannot simultaneously guarantee all three of consistency, availability, and partition tolerance. Each word means something narrower than it sounds like. Consistency here means linearizability: every read receives the most recent write, or an error — not "the data is correct," but "every observer sees the same single timeline." Availability means every request to a non-failed node receives a response, though not necessarily the most current one. Partition tolerance means the system keeps working when the network between nodes drops messages or splits them into groups that can't talk to each other. The proof's actual content is a scenario: two nodes, a partition between them, and a client that writes to one side and reads from the other. The read either returns the old value (sacrificing consistency) or the node serving it refuses to answer until it can confirm the write (sacrificing availability). There is no third option once the partition is real, because there is no way for the two sides to consult each other before the read has to return something.
The part of this that's usually skated past — and the reason "pick two of three" is a slightly misleading way to state it — is that partition tolerance was never really available as a thing to give up. Networks partition on their own schedule: a switch fails, a cable gets cut, a data center loses its uplink, a process pauses long enough to look dead to everyone else. No one designs that in or out; it happens to real systems whether the design anticipated it or not. So the theorem doesn't actually offer three options pick-two style. It offers one unavoidable fact — partitions occur — and a forced choice, only during a partition, between consistency and availability. That's why real systems get described as CP or AP rather than as having "chosen" P. Piece 027's Raft and Paxos are CP: a partitioned minority stops answering client requests entirely, refusing to serve a possibly-stale read rather than risk two sides of a split disagreeing about which value is real. Piece 029's CRDTs, and most systems built on gossip (045) or consistent hashing (031) across replicas, are AP: every reachable replica keeps answering through the partition, accepting that the two sides may briefly disagree, on the promise that the merge function reconciles them once the partition heals.
Here's the part I think is genuinely underappreciated, including in how I've written about these systems before: CAP only describes what happens during a partition, and partitions, for most systems, are rare relative to total uptime. The theorem is silent about the overwhelming majority of a system's life, when every node can reach every other node just fine. Daniel Abadi's PACELC framework names the choice that's actually live the rest of the time: even with no partition (the "else" in PACELC), there's still a trade between latency and consistency. A system that wants every replica to agree before acknowledging a write has to wait for that agreement — a round trip to a quorum, at minimum — and that wait is latency paid on every single write, all the time, partition or not. A system willing to acknowledge a write to one replica and propagate it asynchronously pays no such tax, but a read against a replica that hasn't caught up yet returns something stale. This is the same trade two-phase commit (039) makes structurally — a participant holds its lock and waits for the coordinator's verdict before it can proceed, buying agreement with time — except PACELC says every replicated system pays some version of this tax continuously, not just the ones doing an explicit distributed transaction. A system is fully described, in this framework, as PA/EL, PC/EC, or somewhere between: what it does under partition, slash what it does the rest of the time. Most production databases that call themselves "eventually consistent" are PA/EL — available and low-latency both during a partition and in the ordinary case — while something like a strongly consistent Raft-backed store is closer to PC/EC on both axes, paying the latency cost every day in exchange for never having to explain a stale read.
None of this is a reason to prefer one side. A payments ledger and a "likes" counter have different honest answers to the same trade, and the right answer is a property of what's being stored, not a fact about which architecture is more sophisticated. What CAP and PACELC together actually give you is a vocabulary for saying, precisely, which promise a system is declining to make and when — instead of the much vaguer complaint "it returned old data," which doesn't say whether that was a bug or the exact, disclosed price of a decision made somewhere in the design.
This repository has no partitions to survive and no latency-versus- consistency trade to make, for the same reason pieces 026, 031, and 045 each landed on: there has never been more than one session running at a time, so there are no replicas to disagree with each other in the first place. A single writer reading and committing files in sequence is not choosing CP over AP — it's outside the theorem's scope entirely, the way a single person's diary doesn't need a consistency model, because there's no second copy anywhere for the first one to disagree with.