Eventual consistency and consensus.
Independent copies of the same data, edited in different places, somehow have to agree. Here is the field that makes that happen, in plain language.
When a salesperson's email, calendar, one or more CRMs, and task list all hold a copy of the same customer, and each can be edited, the copies drift apart. This page explains the field that studies how they come back together: what eventual consistency is, why two-way sync forces a choice, the mechanisms the field uses, and where it is going. The papers behind each idea are linked, so you can read the source yourself.
| Moment | Replica A | Replica B |
|---|---|---|
| Before | Proposal | Proposal |
| Write arrives | Won | Proposal |
| After sync | Won | Won |
When two places can change the same fact, whose change wins, and when does everyone see it.
Eventual consistency and consensus are two answers to that one question.
A replica is a copy of the data. Eventual consistency is the rule that independent replicas are allowed to differ for a short while, and that a defined reconciliation process guarantees they converge to the same value once updates stop flowing. Consensus is the stricter sibling: a protocol by which a set of machines agrees on a single, ordered sequence of operations, even as some of them fail.
The contrast worth holding: strong consistency means everyone sees the latest write immediately, and eventual consistency means everyone sees it eventually. A conflict is two changes that cannot both be true, for example a phone number edited to two different values before the systems could talk. The rest of this page is about how the field tells an ordered update apart from a real conflict, and what it does with each.
| Moment | Replica A | Replica B |
|---|---|---|
| Before edit | Proposal | Proposal |
| After local edit | Won | Proposal |
| After propagation | Won | Won |
The moment more than one system can write, you have copies of the truth that can disagree.
The messy inbox-calendar-CRM-tasks picture is not sloppiness. It is the default state of any system that syncs both ways.
The result that anchors the whole field is the CAP trade-off, proved by Gilbert and Lynch (2002). Under a network partition, when two systems cannot reach each other, you can stay Consistent or stay Available, not both. CAP is a trade-off that bites under partition, not a slogan to pick any two forever.
Read it through the example. When a CRM's interface is unreachable and the salesperson edits a contact, the choice is exact: block the edit and stay perfectly in step, or accept the edit and reconcile when the link returns. Eventual consistency is the name for the second choice done well.
Wait for agreement
- Behavior
- Some requests cannot complete during the partition.
- Benefit
- Preserve the chosen strong consistency guarantee.
Accept locally
- Behavior
- A reachable replica accepts the request.
- Cost
- Copies can diverge and need reconciliation.
Changes happen out of contact.
A task closed on a phone with no signal, or a note typed in a CRM that cannot sync yet. The edit is real, it just has not been seen anywhere else. Reconciliation has to happen on reconnect.
"Latest" is ambiguous.
Clocks on different machines disagree, so a wall-clock timestamp does not reliably say which of two edits came second. Without a shared notion of order, two systems cannot agree which one wins.
The same person, many identities.
One contact appears as A. Rivera, Ana Rivera, and Ana R., spread across systems. Deciding those are one record is itself a conflict problem, and a merge that holds has to not un-merge an hour later.
A synced change can look fresh.
In two-way sync, a change copied into a second system can be read back as a brand-new change and bounce around. Telling an echo apart from a genuine edit is part of the work.
Two true edits, one field.
Two people, or one person on two devices, change the same field at the same time. Neither is wrong. The system has to detect that this is a real conflict and not just a stale copy.
Some copies are reachable, some are not.
Sync rarely fails all at once. One system is up, another is slow, a third is mid-restart. The field's techniques have to make progress without waiting for every copy to be present.
The field reconciles copies in named stages.
Tag the writes, tell updates from conflicts, move the changes around, merge what truly conflicts, and reach for consensus only when one answer is required.
- 01Version
Represent causal history.
- 02Detect
Separate updates from conflicts.
- 03Exchange
Repair replica differences.
- 04Merge
Apply convergent rules.
- 05Coordinate
Use consensus where required.
Five jobs the field separates, each doing one thing on the way from many copies to one view.
1Versioning and causality
Tag every write so order is knowable.
Because machine clocks disagree, the field tracks order by cause, not by time. Each write carries a version that records what it was based on. Compare two versions and you can tell whether one is an ordered update of the other, or whether they are genuinely concurrent and so a real conflict.
Vector clocks and version vectors are the classic tools. Dynamo (DeCandia et al., 2007) uses vector clocks to detect divergent versions of the same key, keeping both when it cannot tell which should win.
Ordered update
v1 → v2 → v3Each update incorporates the preceding history.
Concurrent edits
→ v2-A
v1
→ v2-BNeither edit has seen the other.
2Conflict detection and resolution
Decide what to do with a real conflict.
Once a clash is confirmed, something has to resolve it. The simplest strategy is last-writer-wins, which is easy but can silently drop one of the two edits. Semantic merges do better by using what the data means: two task lists can union, two notes can both be kept, a field can take the larger of two counts.
Bayou (Terry et al., 1995) introduced per-write dependency checks and application-supplied merge procedures: the insight that the application, not the storage layer, often knows the right way to combine two edits. That is the playbook for reconciling changes made while disconnected.
| Strategy | Example effect |
|---|---|
| Last-writer-wins | Keep one phone number by a total timestamp order. |
| Set union | Keep both independently added tags. |
| Review | Ask a person about incompatible contract changes. |
3Replica synchronization
Move the changes around, and find what differs.
Copies have to exchange updates without re-sending everything each time. Anti-entropy is the general name for the background process that compares two replicas and ships only the differences. Gossip spreads updates copy to copy, and Merkle trees let two replicas find exactly which records differ by comparing hashes instead of full contents.
Dynamo (DeCandia et al., 2007) uses anti-entropy with Merkle trees to keep replicas in sync efficiently, so a small divergence costs a small repair.
| Field | Copy A | Copy B |
|---|---|---|
| Name | Acme | Acme |
| Phone version | v3 | v2 |
| Owner | Dana | Dana |
Avoid retransmitting identical fields or ranges when the protocol can identify them.
4Convergent data types
Structures that merge without coordination.
Some data can be designed so that concurrent edits always merge cleanly, by construction, with no central referee. Conflict-free replicated data types, or CRDTs, are the principled version of that idea: Shapiro et al. (2011) define data structures whose merge is automatic and order-independent.
They are a useful mental model for a field that can be edited in two places at once. A set of tags, a counter, or a list of attendees can be built so that two offline edits combine into one sensible result without anyone choosing a winner.
Replica A
Replica B
priority · renewal
5Consensus, when you need one answer
Agree one ordered history that every copy replays.
Sometimes divergence is not acceptable and exactly one outcome has to be official: which of two conflicting edits is the record of truth, or the single order in which operations applied. That is a consensus problem. A group of machines elects a leader and agrees on one ordered log, even as some of them fail.
Paxos, introduced by Lamport (1998), is the foundational result. Raft (Ongaro and Ousterhout, 2014) is the understandability-first reformulation now common in practice: leader election plus a replicated, ordered log. Consensus costs coordination, which is why the field reaches for it only where one authoritative answer is required.
| Replica | Log state |
|---|---|
| Leader | e1 · e2 · e3 |
| Follower A | e1 · e2 · e3 |
| Follower B | e1 · e2 · catching up |
Lagging replicas receive the agreed entries.
Messy, disagreeing copies become one state a person can trust.
At the field level: a single current view, edits that flow both ways without overwriting each other, work that survives going offline, and a record of why one edit won.
The value of the field is that it names the trade-offs exactly and gives proven techniques for turning a pile of disagreeing copies into a view someone can act on. For the connected knowledge layer described at the top, a salesperson's email, calendar, CRMs, and tasks unified into one de-duplicated picture, these are the outcomes the field makes reachable. How any given product delivers them is a separate question this page does not answer.
One current, de-duplicated view.
The same contact under four spellings resolves to one record, so a person can act without checking four tabs for the latest detail.
Two-way edits that do not clobber.
A note added in one system and a task closed in another both survive, because the field distinguishes an ordered update from a real conflict.
Offline-tolerant work.
Edits made out of contact, in a car or on a plane, reconcile on reconnect instead of being lost or blocking the work.
An auditable history.
Because changes are versioned and ordered, you can show where a value came from and why one edit became the official one.
Everything here describes the field. It makes no claim about how any particular system syncs, merges, or de-duplicates.
The direction the field is heading.
We describe the direction, not a roadmap of our own.
Causal and stronger-but-available models.
Consistency models that keep related edits in a sensible order without paying for full coordination, so copies stay both responsive and reasonable.
Convergent types into the mainstream.
CRDTs are moving out of research and into everyday collaborative and local-first tools, where edits happen offline and merge later by default.
Database and application meet in the middle.
The storage layer and the application are converging on a common language for merges, so meaning-aware reconciliation is less of a one-off.
Human decisions, still in the loop.
A merge rule is a small piece of human judgment. Getting those rules right, and keeping them legible, stays an open and human problem.
Testing under failure.
Verifying that a real system actually converges when networks and machines fail, the kind of work that fault-injection testing popularized, remains nontrivial.
The papers behind this page.
- Gilbert and Lynch (2002). Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services. ACM SIGACT News.
- Terry et al. (1995). Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System. SOSP.
- DeCandia et al. (2007). Dynamo: Amazon's Highly Available Key-value Store. SOSP.
- Shapiro, Preguica, Baquero, Zawirski (2011). Conflict-free Replicated Data Types. SSS.
- Lamport (1998). The Part-Time Parliament. ACM Transactions on Computer Systems.
- Ongaro and Ousterhout (2014). In Search of an Understandable Consensus Algorithm (Raft). USENIX ATC.
- Vogels (2009). Eventually Consistent. Communications of the ACM.
Keep reading.
Sibling explainers in the Research section.
Talk. Done.
One current view of every customer, kept current while you just talk. See it on a real call.
No app required. Just your phone number.