Short answers to what readers ask most about this topic.
What eventual consistency guarantees, how replicas converge with LWW, version vectors and CRDTs, and which features can tolerate stale reads and which cannot.
Matthews Wong
Software Engineer
Key Takeaway
Eventual consistency means that if no new writes arrive, every replica of an item eventually returns the same, last-written value. It is acceptable for feeds, like counts and profile fields, where a briefly stale read is harmless. It is not acceptable for balances, stock levels or uniqueness checks, which need strong consistency at the point of decision.
Picture a carwash ERP where the owner's dashboard shows today's wash count a few seconds behind the cashier tablet. Nobody notices, nobody is harmed. Now picture the same few seconds of lag on the number that says three bottles of shampoo are left, with two cashiers selling the last ones at once. Same mechanism, completely different consequence.
This post answers the question people search for: what is eventual consistency and when is it acceptable? It covers the spectrum from strong to eventual, the session guarantees that make eventual systems feel sane, how replicas resolve conflicts, and a decision checklist. Definitions come from Werner Vogels, the Jepsen consistency models and Wikipedia; the numbers are worked arithmetic or output from a script I ran.
Vogels defines it as a guarantee that if no new updates are made to an object, eventually all accesses will return the last updated value. Read that carefully. It promises where replicas end up, not what any reader sees on the way there. During the gap, two readers can get two different answers, and the same reader can even get an older answer after a newer one.
The reason systems accept this is cost. Waiting for every replica to confirm each write makes writes slow and makes them fail when a replica or a link is down. Acknowledging a write locally and propagating it in the background keeps writes fast and available, and pays for it with a window of disagreement. I wrote about why that trade is forced by network partitions in the CAP theorem post, and about the replica lag that produces the window in the read replicas post, so here the focus stays on the concept and the decision.
Consistency is a spectrum, not a switch. The useful way to place a system is by what a reader is promised during the gap. The table lists the points I use when reviewing a design.
| Model | What the reader is promised | What it costs | Typical fit |
|---|---|---|---|
| Strong (linearizable) | Every read sees the latest acknowledged write, as if there were one copy | Coordination on every write; slower, and unavailable on the minority side of a partition | Balances, stock at checkout, unique constraints |
| Session guarantees | A client sees its own writes and never sees time go backwards | Routing or version tracking per client; other clients may still be stale | Profile edits, settings, a user's own posts |
| Eventual | If writes stop, all replicas converge on the same value | Stale and out-of-order reads are possible; concurrent writes need a conflict rule | Feeds, view counts, analytics, caches |
| Strong eventual (CRDT) | Eventual, plus replicas that have seen the same updates hold the same state | Data must be modelled as a mergeable type; not every rule can be expressed | Counters, sets, collaborative editing |
Notice that eventual consistency is the weakest row, not a different category. Most real systems sit in the second row: they are eventually consistent underneath and add session guarantees on top, which is the next question.
Pure eventual consistency feels broken to users because it lets a person lose their own edit. Session guarantees fix the worst of that without full strong consistency. Two of them matter most in practice, and both are defined precisely by Jepsen and Vogels.
Both guarantees are per process. They say nothing about what a different user sees, which is exactly why a feed can show your new comment to you while a friend still sees the old thread. That is acceptable for a comment and unacceptable for a payment.
Sticky routing is the cheapest way to buy both guarantees: pin a user to one replica, or to the primary for a short window after they write. It gives the user a coherent view without making the whole system strongly consistent.
Convergence needs a rule for what to do when two replicas accepted different writes to the same item. Wikipedia lists last writer wins as a widespread reconciliation approach, alongside anti-entropy exchanges and read repair. The script below runs two of the rules side by side: last-write-wins on a text field, and a CRDT counter on a stock number.
// convergence.ts (run with: node convergence.ts on Node 22.18+, or npx tsx)
// Two replicas accept writes while partitioned, then exchange state.
type Lww = { value: string; ts: number; node: string };
type PnCounter = { inc: Record<string, number>; dec: Record<string, number> };
// LWW register: highest timestamp wins; node id breaks ties so BOTH replicas
// pick the same winner. Without the tie-break they could swap values forever.
const mergeLww = (a: Lww, b: Lww): Lww =>
a.ts !== b.ts ? (a.ts > b.ts ? a : b) : a.node > b.node ? a : b;
// PN-counter: one slot per node, merged by taking the max of each slot.
// max is commutative, associative and idempotent, so merge order never matters.
const maxSlots = (x: Record<string, number>, y: Record<string, number>) => {
const out: Record<string, number> = { ...x };
for (const [n, v] of Object.entries(y)) out[n] = Math.max(out[n] ?? 0, v);
return out;
};
const mergeCounter = (a: PnCounter, b: PnCounter): PnCounter => ({
inc: maxSlots(a.inc, b.inc),
dec: maxSlots(a.dec, b.dec),
});
const total = (c: PnCounter) =>
Object.values(c.inc).reduce((s, v) => s + v, 0) -
Object.values(c.dec).reduce((s, v) => s + v, 0);
// Case 1: one field edited on both sides during the partition
const a: Lww = { value: "Jl. Merdeka 1", ts: 1000, node: "A" };
const b: Lww = { value: "Jl. Sudirman 9", ts: 1004, node: "B" };
console.log("LWW A merges B ->", mergeLww(a, b).value);
console.log("LWW B merges A ->", mergeLww(b, a).value);
// If B's clock runs 10 ms behind, its later edit carries ts 994 and loses silently:
const bSkewed: Lww = { ...b, ts: 994 };
console.log("LWW skewed B ->", mergeLww(a, bSkewed).value, "(B's newer edit is lost)");
// Case 2: stock starts at 10; A sells 3 and B sells 4 while partitioned
const base: PnCounter = { inc: { A: 10 }, dec: {} };
const left: PnCounter = { ...base, dec: { A: 3 } };
const right: PnCounter = { ...base, dec: { B: 4 } };
const lwwTotal = 10 - 3; // LWW on a plain number: A's write (7 left) wins, B's 4 sales vanish
console.log("LWW counter ->", lwwTotal, "left (true answer is 3)");
const m1 = mergeCounter(left, right);
const m2 = mergeCounter(right, left);
console.log("CRDT counter A<-B =", total(m1), " B<-A =", total(m2), " idempotent =", total(mergeCounter(m1, m1)));I ran it and the output is shown here unedited. Both replicas pick the same address, which is convergence. But LWW is only as good as the clocks: shift one replica by 10 ms and the genuinely later edit is silently discarded. The stock case is worse, because LWW on a plain number keeps one side's value, so B's 4 sales vanish and stock reads 7 left when the true answer is 10 minus 3 minus 4, which is 3.
LWW A merges B -> Jl. Sudirman 9
LWW B merges A -> Jl. Sudirman 9
LWW skewed B -> Jl. Merdeka 1 (B's newer edit is lost)
LWW counter -> 7 left (true answer is 3)
CRDT counter A<-B = 3 B<-A = 3 idempotent = 3The counter converges to 3 in either merge order, and merging a state with itself changes nothing. That follows from the requirement Wikipedia states for state-based CRDTs: the merge function must be commutative, associative and idempotent. Version vectors are the third tool. Each replica keeps a counter per node, and one write supersedes another only if its vector is greater or equal everywhere. Take A at A:2, B:0 and B at A:1, B:1. Neither dominates, so the writes were concurrent, and the system keeps both as siblings for the application to merge instead of guessing a winner.
LWW never reports a conflict. It converges, so every dashboard looks healthy, while data is being thrown away. Use it only for fields where losing one of two concurrent edits is genuinely fine, and never on a number that is supposed to add up.
The deciding question is not how important the data is. It is what happens if one reader acts on a value that is a few seconds old. Here is how that plays out for features I would meet in ERP, POS and web apps.
| Feature | Tolerates stale reads? | Why | What to do |
|---|---|---|---|
| News or activity feed | Yes | A post appearing seconds late harms nobody | Eventual, with read-your-writes for the author |
| Like or view counter | Yes | Approximate is fine, but increments must not be lost | CRDT counter or batched atomic increments |
| Profile or settings edit | Mostly | The editor must see their own change; others can lag | Read-your-writes, LWW acceptable |
| Account balance or payment | No | A stale balance allows an overdraft or a double spend | Strong consistency on the authoritative ledger |
| Stock at checkout | No | Two sellers can each sell the last unit, as in the 10 minus 3 minus 4 example | Atomic decrement or reservation at the primary |
| Unique username or invoice number | No | Two replicas can each accept the same value | Unique constraint enforced in one place |
The pattern is that reads are cheap to be wrong about, and decisions are not. A stock figure shown on a product page can be eventual. The same figure at the moment of sale cannot. Most systems need both, so the real design choice is where the strong boundary sits, not whether to have one.
Run the feature through these five questions in order. The first no sends you to strong consistency for that path.
A yes to the first two means strong consistency for that write path, even if everything around it is eventual. If you answer no to those and have a merge rule for the third, eventual consistency is a sound choice, not a compromise.
Eventual consistency is a property of the storage layer, but users meet it in the interface, and the interface decides whether the gap feels like a bug. These patterns hide the gap or make it honest.
The last pattern is the one that lets the rest of the page stay eventual. The cheap, fast, possibly stale read drives browsing, and one strong check guards the action that cannot be undone.
Eventual consistency is acceptable when a stale read is cheap to be wrong about and every concurrent write has a merge rule you chose on purpose. It is not acceptable for balances, stock at the moment of sale or uniqueness. Keep the strong boundary small, add read-your-writes for the person who just wrote, and never let last-write-wins touch a number that has to add up.