Replication and quorums
Predict acknowledged-write loss after failover, calculate quorum overlap and failure tolerance, and reason about repair and stale replicas.
27 min8 steps
By the end you can
- Estimate acknowledged writes at risk from a specified async replication gap
- Calculate intersecting read and write sets and majority failure tolerance
- Choose acknowledgement and read routing policies for a stated consistency requirement
- Distinguish read repair, anti-entropy, hints and tombstone retention
Copies protect different promises
A leader orders writes; followers copy them and may lag. Sync waits for a stated replica condition; async does not. Say what "acknowledged" means: received, flushed, or applied. Replicas copy accidental deletes too.
A successful write can disappear after failover
Async follower 2 s behind a 500 writes/s leader: lose the leader and about 1,000 acknowledged writes are at risk. Lag in log positions beats a time average.
t − 2 s
Last write the follower has
t
Leader and disk lost
t + 5 s
Follower promoted, 1,000 writes gone
Loading question…
Read routing defines the freshness promise
Update an address, read a lagging follower, see the old value: read-your-writes is broken. Read the leader, or a follower that has applied that log position.
Overlap requires a strict inequality
Write reaches W, read asks R. They must overlap if R + W > N.
R = 2 (sum 5)
- Can read the 2 that missed the write
R = 3 (sum 6)
- Always touches a replica with the write
Loading question…
Stronger acknowledgements can reduce availability
Majority reads and writes of 5 replicas need 3 live, connected nodes. Lower thresholds keep operations moving but weaken the contract.
Loading question…
Repair has several paths
Read repair
- Fixes what reads touch
- Cold keys stay stale
Anti-entropy
- Background compare
- Merkle trees find ranges
Hinted handoff
- Holds write for a down node
- Needs expiry; not proof
A deletion needs evidence too
A tombstone records a delete so repair can spread it. Keep it longer than the longest outage plus repair time, or old data returns. Fence the old leader too.
Day 0
Delete + tombstone; replica C offline
Day 10
Tombstone garbage collected
Day 12
C rejoins with old value: resurrected
Check your mastery, then lose a leader
Score 80% or more. Say whether replicas are fixed, what an ack means, and whether survivors can talk.
Mastery check
5 questions on fresh variants. One attempt each, no time limit. Score 80% or more to master the lesson.
In the sandbox, lose an async leader before catch-up and compare with a synchronous policy. For leaderless, use a three-replica KV store with R = 2 and W = 2 and drop one, then two, replicas. A successful overlapping read is not a linearizability proof.
Answer this step to continue.