Two writes, no order, one answer required

Conflict Resolution

6 lessons. Every one names the guarantee it claims, what a node can know, and how it fails.

Two Writes, No Order, One Answer Required▶ lab

A partition heals and two replicas hold different values for the same key. Neither happened first in any meaningful sense. The system must return something, so something decides — and if you did not choose what, a library default did.

Q · Two replicas accepted different writes to the same key. What decides the outcome?

Last Write Wins Is Data Loss You Chose by Default▶ lab

"Keep the one with the later timestamp" is the most widely deployed conflict resolution rule and the least defensible. "Later" depends on a notion of time that does not exist across machines, and the rule silently discards the write that loses — with no error, no log line, and no way to recover it.

Q · Is it safe to resolve conflicts by keeping the write with the later timestamp?

Version Vectors: Making the Conflict Visible▶ lab

A vector clock scoped to one object, tracked at the replicas rather than at every client. It answers one question exactly — does this version supersede that one, or are they concurrent — and answering it is what turns silent data loss into an explicit decision.

Q · Given two versions of an object, how do I know whether one supersedes the other or they conflict?

Only the Application Knows What the Merge Means▶ lab

The store can tell you two versions conflict. It cannot tell you that two cart additions should union, two balance updates should compose, and two document titles need a human. The merge rule is domain knowledge, and it has to satisfy three algebraic properties or your replicas will never agree.

Q · The system detected a conflict. How do I decide what the value should be?

CRDTs: Deterministic Merge, Not Correct Merge▶ lab

Design the data type so that merging is a mathematical join — order-independent, duplicate-safe, always convergent. It genuinely removes conflict resolution from the write path. It does not make the result the answer your business wanted, and it cannot enforce a global invariant.

Q · Can I make merge automatic and provably convergent — and what does that not give me?

What "Eventually Converges" Actually Requires▶ lab

"Eventually consistent" is a promise with preconditions, and most systems that claim it satisfy them only most of the time. Convergence needs delivery to every replica, a merge that is order-independent, and a quiet period in which to finish. Remove any one and replicas diverge permanently.

Q · My system says it is eventually consistent. What has to be true for that to actually happen, and how would I know if it stopped?