Replication and consistency

Linearizability makes each operation appear to take effect at one instant between its invocation and response, respecting real-time order. If a write has completed before a read begins, the read cannot return an older value in a linearizable register. Concurrent operations can be ordered either way if that order fits the history. Eventual consistency instead permits temporary disagreement under specified convergence conditions; it is often appropriate for derived views, but those conditions and conflict rules still need definition.

Serializable transaction isolation concerns whether committed transactions are equivalent to some serial ordering; by itself it does not add real-time ordering across transactions. Strict serializability combines those ideas. A database's read isolation and its replication durability settings are also separate dimensions. PostgreSQL's serializable transactions can abort to prevent anomalies, so clients must retry an entire failed transaction correctly. Do not infer a global consistency guarantee merely from the word replica or from one strong local transaction setting.

With $N$ replicas, a majority contains $\lfloor N/2\rfloor+1$ members. Any two majorities overlap. More generally, fixed read and write sets overlap when $R+W>N$. Overlap can ensure that a read encounters a replica that participated in a write, but the reader still needs correct version selection, write-completion rules, concurrency handling, and recovery. Sloppy quorums or partial writes change the argument. Arithmetic alone does not prove linearizability, transaction isolation, or durability.

Failures are not always independent. Three replicas on one host or in one power domain can disappear together. A majority-based consensus group of $2f+1$ voting members can continue making decisions with $f$ unavailable members under its protocol and network assumptions. It cannot guarantee progress in every asynchronous execution. During a network partition, a protocol preserving one decision history may have to stop accepting writes in a minority rather than let both sides invent incompatible histories.

Raft orders commands through a leader and replicated log, using terms and voting rules to preserve committed history across leader changes. A former leader can remain alive after losing authority. For safe unlogged reads, a new leader first establishes committed current-term state, commonly with a no-op entry; a read then requires confirmation of current leadership and application through its established read position. Otherwise an apparently live leader may return stale data. Lease-based alternatives add explicit timing assumptions.

Infrastructure often coordinates external resources such as serving endpoints or storage writers. A stale controller may continue acting even after another wins election. Fencing tokens make the protected resource reject operations from older leadership generations, provided the resource actually checks them. A distributed lock without fencing is not an automatic defense against a paused owner resuming late. Test partitions, delayed messages, leader crashes, and stale clients against documented invariants; successful happy-path replication is weak evidence about failover safety.