Two-way sync and conflict resolution.
The same customer lives in your inbox, your calendar, one or two CRMs, and your task list. Keeping every copy in agreement, in both directions, is the field this page is about.
Two-way, or bidirectional, sync keeps many independent copies of the same information agreeing with each other while people keep editing all of them at once. We walk it the way the field is built: what it is, why it is hard, how a system merges concurrent changes, what that unlocks, and where it is heading. The papers behind each idea are linked, so you can read the source yourself.
Keeping many copies in agreement, in every direction.
A one-way feed mirrors a single source into a single destination. Two-way sync lets every copy be edited, then merges the changes flowing all ways at once.
Picture the salesperson's working life. The same account shows up in an inbox thread, a calendar event, one or two CRMs, and a follow-up task. Each tool keeps its own copy with its own fields. Change a phone number in one place and the others do not know. A deal reads "closed" in one CRM and "open" in another. The same contact exists three times under three spellings.
The field has plain vocabulary for this. A replica is one copy of the data. Convergence is when all replicas reach the same state once they have seen the same updates. Reconciliation is the act of bringing diverged replicas back into agreement. And de-duplication, or entity resolution, is deciding that two records describe the same real-world thing. In the example, each tool is a replica of what is known about the account, and the connected view is the converged result: one record per person, company, meeting, and deal.
Two-way sync is strictly harder than one-way mirroring, because changes originate in many places and can disagree. That possibility of disagreement has a name. It is conflict, and resolving it is the rest of this page.
One-way mirror
- Source
The source changes.
- Destination
A copy receives the change.
Two-way sync
- CRM A or CRM B
Either side can accept an edit.
- Reconcile
Exchange changes and apply the chosen conflict policy.
The copies diverge faster than they can talk.
Networks are slow or down, edits arrive out of order, and "latest" is ambiguous when clocks disagree. Each of these is a known, studied problem.
You cannot have it all during an outage.
When the network partitions, a system can stay available or stay strongly consistent, not both at once. Sync across phones, laptops, and third-party CRMs lives with frequent partitions, so most practical systems choose availability plus eventual consistency: replicas may differ briefly, then converge once they communicate.
Two edits, neither first.
Two edits made before the replicas have talked are concurrent: neither happened before the other. You cannot just keep the newer one, because there is no agreed clock to say which is newer. That is the core reason conflicts exist at all.
Wall clocks lie.
Clock skew, daylight saving, and devices set wrong make timestamps untrustworthy. Logical clocks, such as Lamport timestamps and vector clocks, track what each replica had already seen, so a system can tell "happened-before" from "concurrent" without trusting the wall clock.
Merging records is not merging fields.
Beyond combining fields, a system must decide that "Acme Corp", "Acme Corporation", and "ACME Inc." are one company. That is entity resolution, or record linkage, a distinct hard problem layered on top of sync. It does not solve itself when you merge the fields.
Every system models a "deal" differently.
One CRM's contact, deal, and stage do not line up cleanly with another's. Mapping fields across systems, and round-tripping them back without loss, is where a large share of real two-way-sync effort actually goes.
A delete is its own conflict.
Delete a record on one replica while another edits it, and a naive merge can quietly resurrect it. Systems keep "tombstone" markers so a delete is not silently undone by a stale edit that never saw it.
The field has a toolbox for merging concurrent changes.
Track what each copy has seen, then pick a resolution strategy per field. Each strategy trades simplicity against how much intent it preserves.
1Track what each copy has seen
Tell "happened-before" from "concurrent".
Before you can resolve a conflict, you have to detect one. Version vectors, also called vector clocks, attach to each value a small record of how many updates each replica had seen when it wrote. Compare two versions and you learn whether one descends from the other, in which case ordering is clear, or whether neither saw the other, in which case they are concurrent and must be reconciled. Dynamo (DeCandia et al., 2007) popularized version vectors for exactly this, alongside the choice to stay available and reconcile later.
| Version | Vector |
|---|---|
| Base | A:1, B:1 |
| Edit X at A | A:2, B:1 |
| Edit Y at B | A:1, B:2 |
Neither vector is greater than or equal to the other in every component.
2Last-writer-wins
Simple, cheap, and lossy.
Attach a timestamp or version to each value and, on conflict, keep the one with the larger stamp. Last-writer-wins, or LWW, is easy to implement and needs little metadata. The cost is that it silently discards the losing edit. That is fine for a field where only the latest value matters, and dangerous for a field where the dropped edit carried real information. The strategy is acceptable per field, not as a blanket rule.
| Update | Phone | Outcome |
|---|---|---|
| 10:02 | 555-0102 | Superseded |
| 10:05 | 555-0199 | Selected |
Example uses a total ordering of timestamps and a tie-breaker.
3Merge and semantic resolution
Combine instead of discard.
When both edits matter, combine them by the meaning of the data. A set of meeting attendees can union. Two notes can concatenate. A counter can sum. There is no single generic merge, because the right combination depends on what the field means, which is why a blanket "just sync it" rarely fits every field. Choosing the merge rule per field is much of the real design work.
Replica A
Replica B
Rep · Client · Marcus
4Operational transformation
Transform an edit against the edits it missed.
Represent each change as an operation, such as insert or delete at a position, then transform an incoming operation against the operations it did not see, so every replica applies a consistent final result. Operational transformation, or OT, is the classic approach behind real-time collaborative text editors. It is powerful and has historically been tricky to get correct. The idea traces to Ellis & Gibbs (1989), which set convergence and causality preservation as the goals.
CAT
| Concurrent operation | Original position |
|---|---|
| A inserts B | Before C, index 0 |
| B deletes T | Index 2 |
Insert B to get BCAT. Shift the deletion to index 3, then delete T to get BCA.
5Conflict-free replicated data types
Design the data so it cannot conflict.
A conflict-free replicated data type, or CRDT, is built so concurrent updates always merge deterministically, with no coordination. Any two replicas that have seen the same set of updates compute the same state. Two flavors exist: state-based, where replicas exchange and merge full states through a merge function that is commutative, associative, and idempotent, and operation-based, where replicas broadcast operations that commute. CRDTs were formalized in Shapiro et al. (2011). Later work, such as Kleppmann & Beresford (2017), extends them to nested JSON-like documents, which is closer to how CRM and calendar records are actually shaped. The trade is extra metadata in exchange for convergence without conflicts, by construction.
Replica A
Replica B
open · priority · renewal
6Application-defined rules and tombstones
When the domain has to decide.
Sometimes no generic rule fits, and the application has to weigh in. Bayou (Terry et al., 1995) lets each write carry a dependency check and a merge procedure, so the system detects a conflict and runs domain-specific logic to resolve it, rather than forcing one global rule on every field. Deletion gets its own care: a tombstone marks a record as deleted so a stale edit that never saw the delete cannot quietly bring it back. It is worth being honest about the limit here. Convergence is not the same as correctness. Replicas can agree on a value that is not the one a person wanted. Conflict resolution reduces lost edits, it does not guarantee the right answer, which is exactly why merge rules and de-duplication matter.
- Replica A deletes contact 482
Retain a tombstone recording the deletion.
- Replica B sends a stale edit
Its phone change predates knowledge of that deletion.
- Apply the deletion policy
The stale edit does not recreate the contact.
One current, de-duplicated view to build on.
When the copies actually agree, the work that sits on top has solid ground. Here is what the field makes possible, described at the field level.
Back to the salesperson. Inbox, calendar, CRMs, and tasks stop being four versions of the truth and become one connected knowledge layer: one record per real person and deal, reflecting the latest agreed state. This is the relatable problem two-way sync is built to address, and the discipline above is how the field gets there.
One record per real thing.
De-duplication collapses "Acme Corp", "Acme Corporation", and "ACME Inc." into a single resolved record, so a person or a deal appears once, not three times.
Edits made anywhere are honored.
Update a phone number on a phone, mark a task done in a CRM, and the change is reflected everywhere the field allows it, without manual re-entry into each tool.
Offline work reconciles cleanly.
Changes made on a plane or in a dead zone merge later instead of being lost or overwriting good data, because the system tracked what each copy had seen.
A trustworthy base layer.
Search, reporting, and assistance are only as reliable as the records under them. When the underlying copies agree, downstream work can lean on the connected view. See Knowledge and connection graphs.
This page describes the field, not any one product's plumbing. The techniques above are the field's, and which one fits a given field of data is always a per-case trade-off.
The direction the field is heading.
We describe the direction, not a roadmap of our own.
From counters to documents.
Early CRDTs handled counters, sets, and registers. Later work extends them to nested JSON-like documents, lists with moves, and text, narrowing the historical gap with operational transformation.
A full copy on every device.
A design direction that puts a complete replica on each device and treats sync and merge as core concerns, aiming for both real-time collaboration and user ownership of data, as set out in the local-first essay.
Rivals, now measured head to head.
The two camps, long treated as opposites, are increasingly compared directly and combined. The practical question is which guarantees and overheads fit a given workload, not which one wins in the abstract.
From string match to learned linkage.
De-duplication across systems is moving from brittle string matching toward learned and graph-based linkage, which tightens the "one record per real thing" promise. See Embeddings and vector search.
The papers behind this page.
- Shapiro, Preguiça, Baquero, Zawirski (2011). Conflict-Free Replicated Data Types. SSS 2011.
- Ellis & Gibbs (1989). Concurrency Control in Groupware Systems. ACM SIGMOD 1989.
- Terry, Theimer, Petersen, Demers, Spreitzer, Hauser (1995). Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System. SOSP 1995.
- DeCandia et al. (2007). Dynamo: Amazon's Highly Available Key-value Store. SOSP 2007.
- Kleppmann & Beresford (2017). A Conflict-Free Replicated JSON Datatype. IEEE TPDS 2017.
- Kleppmann, Wiggins, van Hardenberg, McGranaghan (2019). Local-first software: you own your data, in spite of the cloud. Onward! 2019.
Keep reading.
Sibling explainers in the Research section.
Talk. Done.
One current view, kept in agreement, so you can just talk and trust the record. See it on a real call.
No app required. Just your phone number.