Consistency and replication
What a read may return after a write, and what each stronger promise costs. The consistency ladder, quorum arithmetic, the three replication topologies, sync against async, the defences against replication lag, and CAP and PACELC said the way they are meant.
What is the difference between strong and eventual consistency?
Strong usually means linearizable: every read returns the latest completed write, as if there were one copy of the data. Eventual means only that the copies agree once writes stop, so a read may return anything older in the meantime, including a value older than one you already saw. Between them sit causal consistency and the session guarantees, read-your-writes and monotonic reads, which are what most user-facing features need. Pick the weakest rung whose worst case the product can accept.
What does W + R > N mean?
N is the number of copies of a key, W the replicas a write waits for, and R the replicas a read asks. When W plus R is more than N, every read set and every write set share at least one replica, so a read reaches a copy that has the latest acknowledged write. With three copies, two and two is the classic setting. It does not make the store linearizable by itself: concurrent writes still need versions to order them.
Should replication be synchronous or asynchronous?
Synchronous replication means the client hears ok only after a replica has the write too, so a failover loses nothing, and every write pays the round trip to the replica. Asynchronous means the client hears ok after the primary alone, so writes are fast and a failover loses whatever the replica had not received yet. The common middle is one synchronous replica and the rest asynchronous: failing over to that replica loses nothing, and a write waits for one replica instead of all of them.
Is CAP really "pick two of three"?
No. Network partitions happen whether you choose them or not, so the real choice is what the system does during one: refuse some requests to stay consistent, or answer them and risk stale or conflicting data. PACELC adds the choice that applies the rest of the time: with no partition, you trade latency against consistency, because waiting for more replicas is slower.
When would I pick leaderless replication over a single leader?
When writes must keep succeeding while nodes die and no election pause is acceptable, and the data tolerates concurrent writes being ordered by version or merged. A single leader is simpler, gives one order of writes for free, and is the default; leaderless trades that simplicity for availability, and multi-leader is mostly for writes accepted in several regions at once.