Conflict Copy

When two replicas of the same file or record are edited independently and then synchronised, something must happen. A conflict copy keeps both: the original retains one version and the other is preserved alongside it, clearly marked, for the user to reconcile.

It is unglamorous, it produces clutter, and it is the only strategy with the property that no user-authored content is ever discarded.

Why the alternatives lose data

Last-write-wins by timestamp requires trusting a clock. Device clocks are wrong in both directions, sometimes by a great deal, so the surviving version may be the older edit — and the loss is silent.

Automatic merge works where the data shape supports it and fails where intent genuinely conflicts. Two incompatible intentions cannot be reconciled by any algorithm; something has to be chosen, and choosing silently is what users experience as data loss.

Silent resolution of any kind is the underlying failure. Content may be superseded, renamed or flagged — but the user must be able to get it back.

Implementation patterns

• Causal tracking — version vectors or equivalent — so genuine concurrency is detected rather than inferred from timestamps. Without it the system misclassifies ordinary sequential edits as conflicts and actual conflicts as sequences.
• Content-addressed version storage, which makes any superseded version recoverable and deduplicates identical content cheaply.
• Atomic local state transitions, so a crash between writing content and updating sync state leaves a resumable state rather than a file the system believes is synchronised and is not.
• Server time as the ordering authority wherever an order must be established, never client clocks.
• Clear naming and surfacing, so the user notices the conflict copy exists — an unnoticed one is functionally the same as a silent discard.
• Conflict rate and resolution outcome monitored, segmented by type. A rising rate of silent discards is invisible without instrumentation, and by the time users report it the evidence is months gone.

Industry example

File synchronisation products have converged on this over decades of trying cleverer approaches. The pattern that keeps recurring is that users forgive clutter and do not forgive lost work, and that the support cost of an unexplained disappearance vastly exceeds the annoyance of a duplicate file.

The same conclusion appears in offline-capable operational apps: a delivery marked complete on a device and reassigned on the server is a genuine conflict, and there is no technically correct resolution — only a business rule, which must be decided in advance rather than during the incident.

Failure scenarios

• Timestamp-based winners with untrusted clocks.
• Silent discard, the root failure regardless of the mechanism producing it.
• Non-atomic sync state, producing files believed synchronised that are not.
• No causal tracking, misclassifying in both directions.
• Conflict copies created and never surfaced, which users never find.

Trade-offs

Conflict copies push the resolution work onto the user and produce duplicate files that accumulate, particularly for a document edited on several devices where a naive implementation can generate them constantly. That is a genuine usability cost.

The mitigation is not to resolve silently but to reduce genuine conflicts: finer-grained sync so independent edits to different parts of a document do not conflict at all, and CRDTs where the data shape supports automatic convergence. Conflict copies then remain for the cases where intent truly diverges, which should be rare.

Interview question

"Two devices edit the same file while offline and both come back online. Describe every option you have, and tell me which one you would never ship."