What is Eventual Consistency?
Understand eventual consistency in distributed systems — how replicas converge, conflict resolution, and when to trade it off against strong consistency.
Expected Interview Answer
Eventual consistency is a consistency model in which, if no new updates are made to a piece of data, all replicas will converge to the same value over time, though reads immediately after a write may see stale data.
Distributed databases replicate data across multiple nodes for availability and low latency, but propagating a write to every replica instantly is expensive and, per the CAP theorem, often impossible during network partitions. Eventual consistency trades immediate agreement for availability: a write lands on one node and asynchronously propagates to others, so a read routed to a different replica may briefly return an older value. Systems typically use techniques like vector clocks, last-write-wins, or read-repair to resolve conflicting versions once replicas do sync. This model suits use cases like social media likes or DNS records, where brief staleness is acceptable in exchange for high availability and low write latency.
- Keeps the system available even during network partitions
- Lowers write latency by not waiting for every replica
- Scales horizontally across geographically distributed nodes
- Trades strict correctness for throughput where staleness is tolerable
AI Mentor Explanation
Eventual consistency is like the scoreboard operators at different ends of a cricket ground updating their displays moments after a boundary is signalled rather than instantaneously. The instant the ball crosses the rope, the umpire signals it, but each scoreboard operator updates their own board a few seconds later after the signal reaches them. For a brief window one board might still show the old total while another already reflects the four — but within seconds, all boards agree. That brief lag before every replica converges is exactly what eventual consistency describes.
Step-by-Step Explanation
Step 1
Write lands on one replica
A client writes data; it is durably stored on the node that received the request first.
Step 2
Acknowledge without waiting for all replicas
The write is acknowledged to the client immediately, favoring availability and low latency over strict sync.
Step 3
Asynchronous propagation
The update is replicated to other nodes in the background via gossip protocols, replication logs, or anti-entropy jobs.
Step 4
Convergence
Given enough time and no further writes, every replica ends up holding the same value, resolving conflicts via last-write-wins, vector clocks, or read-repair.
What Interviewer Expects
- Definition: replicas converge over time, not instantly, if writes stop
- Trade-off framing against strong consistency using CAP theorem intuition
- A concrete conflict-resolution mechanism (last-write-wins, vector clocks, read-repair)
- A realistic use case where staleness is acceptable (DNS, social counters, shopping carts)
Common Mistakes
- Claiming eventual consistency means data is never correct
- Not mentioning that consistency only converges when writes stop
- Confusing eventual consistency with strong or causal consistency
- Failing to name any conflict-resolution strategy
Best Answer (HR Friendly)
“Eventual consistency means that when data is copied across multiple servers, those copies might briefly disagree right after an update, but they will all catch up to the same value shortly after, as long as no new changes come in. It is a deliberate trade-off systems make to stay fast and available, accepting brief staleness in exchange for not having to wait for every server to agree before responding to the user.”
Code Example
function mergeReplica(localValue, incomingValue) {
// Each value carries a vector-clock-lite timestamp from its origin node
if (incomingValue.timestamp > localValue.timestamp) {
return incomingValue // newer write wins
}
if (incomingValue.timestamp === localValue.timestamp) {
// Tie-break deterministically, e.g. by node id, to avoid divergence
return incomingValue.nodeId > localValue.nodeId ? incomingValue : localValue
}
return localValue
}
// Background anti-entropy job periodically exchanges state between replicas
async function antiEntropySync(replicaA, replicaB) {
const remoteState = await replicaB.fetchState()
for (const [key, incoming] of Object.entries(remoteState)) {
const local = replicaA.get(key)
replicaA.set(key, local ? mergeReplica(local, incoming) : incoming)
}
}Follow-up Questions
- How does eventual consistency relate to the CAP theorem?
- What is the difference between eventual consistency and strong consistency?
- How do vector clocks help resolve conflicting writes?
- What is read-your-writes consistency and how does it differ from eventual consistency?
MCQ Practice
1. Under eventual consistency, when are all replicas guaranteed to hold the same value?
Eventual consistency guarantees convergence over time, provided writes to that data stop.
2. Which technique helps resolve conflicting concurrent writes across replicas?
Vector clocks and last-write-wins are common strategies for determining which of several concurrent writes should win.
3. Eventual consistency is typically chosen over strong consistency to prioritize what?
It sacrifices immediate agreement across replicas in exchange for staying available and responding quickly.
Flash Cards
What is eventual consistency? — A model where replicas converge to the same value over time if no new writes occur.
Why trade consistency for availability? — To keep the system responsive and available even during replication delays or partitions.
Name a conflict-resolution technique. — Last-write-wins using timestamps, or vector clocks to track causal history.
Give a real use case. — DNS propagation, social media like counts, or shopping cart contents.