Replication and Preference Lists
Why this matters: the always-write requirement rules out an entire replication model. Watching it get rejected — and seeing what replaces it — is the clearest example in this chapter of a requirement dictating architecture.
Key takeaway
To ensure durability and availability, data is replicated across multiple nodes. This design uses peer-to-peer replication, where every node can accept reads and writes, because primary-secondary would violate the ability to always write.
Why not primary-secondary
In a primary-secondary architecture, one node handles writes while others replicate and serve reads.
Two problems, and the second is fatal here:
- It introduces replication lag.
- If the primary fails, the system cannot accept writes until a new primary is elected — a single point of failure for write availability.
Our functional requirement was the ability to always write. A model with a window where writes are impossible does not satisfy it. So primary-secondary is out — not because it is worse in general, but because it contradicts a stated requirement.
Peer-to-peer replication
In a peer-to-peer approach, all nodes act as primaries. Any node can handle reads and writes, replicating data to peers to stay updated.
Replicating to all nodes is inefficient and costly, so we choose a replication factor — typically three or five nodes.
Each data item is replicated at n hosts, where n is configured per instance of the key-value store. Choosing n = 5 means the data lives on five nodes.
The coordinator and the preference list
The node handling a read or write is the coordinator. It is directly responsible for the keys assigned to it.
A coordinator assigned key "K" is also responsible for replicating that key to the n-1 successors on the ring, moving clockwise. That list of successor virtual nodes is the preference list.
With a replication factor of n = 3: key "K" is replicated to nodes B, C, and D; key "L" is replicated to C, D, and E. Note that a node is a coordinator for some keys and a replica for others — there are no distinguished roles, which is exactly what the hardware-heterogeneity requirement asked for.
The CAP posture
In CAP terms, key-value stores of this kind prioritize Availability over Consistency (AP).
If a network partition occurs, nodes continue to accept requests even when they cannot communicate with replicas. The system stays operational — and may develop temporary data inconsistencies.
When the connection is restored, nodes must sync data to resolve those conflicts. That reconciliation problem is what the next lesson solves with data versioning.
Key takeaway
Peer-to-peer replication with preference lists means no node is special, so there is no node whose loss stops writes. The price is that the system must be able to reconcile divergent copies — which is the subject of the next lesson.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "We replicate the data to three nodes." |
| L5 | Justifies the model: "peer-to-peer rather than primary-secondary, because a primary failing would block writes and we need to always accept them." |
| Staff+ | Handles placement correctly: "the preference list walks clockwise for n successors but skips virtual nodes on a physical machine already in the list — otherwise all three replicas can land on one box. Ideally it spans data centers too. And accepting writes on both sides of a partition means I now owe the design a reconciliation mechanism." |
Next: reconciling copies that disagree.