Replication and Consistency
Replication and consistency describe how a system keeps the same data on several machines, and what a read is allowed to return while those copies catch up. Replication improves availability and latency, but consistency is the contract that says whether a client must see the latest write, its own write, or merely eventual convergence.
Replication is necessary because a single machine is a poor place to put important state. It can fail, be far from users, or become overloaded. Keeping copies lets the service continue through node failure and serve reads nearer to clients. The catch is that copying is not instantaneous. Once there are multiple copies, the system must define which copy a read consults and whether that answer may be old.
In a leader-based design, writes first reach a leader, which records the change and sends it to followers. If a client writes to the leader and then reads from a follower before that follower has applied the change, the read can legitimately return the previous value. Quorum systems use overlapping read and write acknowledgements, for example requiring enough replicas for the read set to intersect the write set, reducing the chance of reading only stale copies.
The trade-off is that stronger guarantees usually cost latency, availability, or operational simplicity. Waiting for more replicas before acknowledging a write makes failures and slow links visible to users. Allowing local or follower reads is faster, but may show stale state. Multi-leader and leaderless systems add conflict resolution, where policies such as last-write-wins can silently discard a valid update if ordering is inferred poorly.
Engineers meet this in databases, caches, edge storage, and read-replica architectures. A profile update followed by a page refresh may look broken if the refresh reads from a lagging replica. Commonly misunderstood: replicated does not mean strongly consistent. The honest answer to “can this read be stale?” depends on the write path, the read target, the replication mode, and the configured consistency level.
Common questions
- Why can I read old data immediately after a successful write?
- Because success may mean the leader accepted the write, not that every replica has applied it. If the following read is routed to a replica that is behind, it can return the old value. Read-your-writes consistency prevents this for that client, often by routing the session to the leader or tracking versions.
- Does eventual consistency mean data can be wrong forever?
- No. Eventual consistency means replicas should converge once new writes stop and replication completes. During the window before convergence, different replicas may return different answers. It is a weaker promise than strong consistency, not an absence of rules, but applications must tolerate temporary disagreement.
- Is quorum replication the same as strong consistency?
- Not automatically. Quorums can make reads overlap writes, which helps avoid reading only old replicas, but correctness also depends on how writes are ordered, how failures are handled, whether stale responses are repaired, and what the database means by commit. The parameters matter, but so does the protocol.