Redundancy cannot be amortized

Why is a second copy the one cost with no escape, and why is every durability figure a claim about correlation?

Where redundancy comes from

The two parts before this spent resources. Retry spent the dependency's capacity. Replay spent headroom. Checkpoints spent write bandwidth. Dedup spent state. None of them created the thing they spend from. Durable copies of the data are Persistence & Durability's subject. This article is about the other thing redundancy buys: a system that keeps answering while a node is gone. It is also the only part whose mechanisms run continuously, whether or not anything has failed.

What is new here: redundancy is the only mechanism in this whole subject that cannot be amortized. Every other cost has an escape. You can batch it, cache it, precompute it, approximate it or defer it. A second copy has no such escape, because the second copy is the thing you are buying. Compression reduces its size. Nothing reduces its existence. So cost is not a tuning parameter here. It is the mechanism. The honest question is not "how durable can we be?" but "how much are we buying, and against which failure?"

The second new thing: earlier parts reasoned about one failure. Redundancy arithmetic is about how many simultaneous failures you survive. The answer is always a small integer, always chosen, and always stated as if it were derived. The number of failures f you tolerate is a purchasing decision dressed as an engineering result.

The third: all the arithmetic of this article rests on an assumption that is false almost everywhere. Multiplying failure probabilities requires independence. But replicas share power, network, racks, firmware, deploy pipelines, operators and code (correlated failure).

Every mechanism in this article is also a placement on the trade-off between consistency (do readers see the latest write?), availability (does the system answer?) and latency (how fast?). Each mechanism moves the cost on that surface. None resolves it.