NoSQL · Data models beyond tables

How does eventual consistency work and how do you handle it?

Mediumeventual consistencyreplicationsession guaranteesUpdated Oct 2026
Quiz this track

Short answer

Eventual consistency means replicas converge once writes stop and replication catches up. Applications handle the window with idempotency, versioning, read-your-writes routing, and UX that tolerates or explains stale data.

A write is acknowledged by one replica and propagated asynchronously to others. Different replicas can return different values for a period. The guarantee is convergence, not immediacy, and it says nothing about how long the window lasts.

js
async function updateProfile(userId, patch) {
  const next = { ...patch, version: Date.now() };
  await store.put({ pk: "USER#" + userId, ...next });
  await cache.del("user:" + userId);
  return next;
}

async function readProfile(userId, minVersion) {
  const item = await store.get({ pk: "USER#" + userId });
  if (item.version < minVersion) {
    return store.getStrong({ pk: "USER#" + userId });
  }
  return item;
}
Version checks let a client detect that a replica has not caught up and fall back to a stronger read or retry.

Guarantees that make it usable

  • Read-your-writes: after a write, that client sees its own change, often by routing to the leader
  • Monotonic reads: a client never moves backwards to an older version
  • Writes follow reads: a write is ordered after the read it depended on
  • Causal consistency: operations that are causally related are seen in order by everyone

Design mutations to be idempotent, because retries and duplicate delivery are normal. Use a client-generated request id or a conditional write so replaying the same operation does not double-charge or double-append.

Eventual consistency is not a licence to ignore correctness. Some operations, such as inventory reservation or balance transfer, need a strong read or a transaction even in an eventually consistent system.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1How would you implement read-your-writes?
  2. 2What makes a write idempotent?
  3. 3How long can the inconsistency window last?
  4. 4Which operations can never be eventually consistent?

Say it in the interview

Eventual consistency means replicas converge after writes stop, but reads can be stale in the meantime. In practice I make writes idempotent, attach versions or timestamps, and use session guarantees like read-your-writes by routing the client to the leader for a short period. I also design the UX and retries around the possibility of stale data. For operations where stale data is unacceptable, such as inventory or money movement, I use a strong read or a transaction instead of hoping the lag is small.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live NoSQL mock interview and get scored feedback on depth, clarity and confidence.