Sync Is a Lie

“In sync” is a status message, not a state.

What it actually means

As of the last successful exchange, no device reported anything the service couldn’t reconcile.

Not: the devices currently hold the same bytes.

The hard constraint

A sync service cannot ask you.

It decides immediately, using a timestamp, on clocks that don’t agree.

Last week’s four grounds

  • Possession: meaningless, every device has a copy
  • Position: unknowable, the service doesn’t know who your supervisor is
  • Consensus: can’t be polled
  • Recency: the only one left

So it uses recency

Which is why it is wrong on a predictable schedule.

Two device timelines, laptop and phone, in sync until connectivity drops. Each is edited independently while offline; on reconnect the service writes a conflict copy rather than choosing.

budget.xlsx
budget (Naledi's conflicted copy 2027-04-14).xlsx

Not a malfunction. The service declining a decision it has no authority to make.

The failure is downstream

Nobody reads the conflict copy.

It looks like litter rather than a finding.

It is not a bad service

Under a network partition, no system can be both fully consistent and fully available. That is a proved result, not a product decision.

The conflict copy is what choosing availability looks like from inside your folder.

Next week

A conflict copy preserves both versions intact.

Next: loss with nothing duplicated and nothing overwritten.

Sources

  • Time, Clocks, and the Ordering of Events in a Distributed System Leslie Lamport, Communications of the ACM 21(7), 1978, 558–565. Why “which happened later” is not a question separate machines can answer from their own clocks. dl.acm.org
  • Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services Seth Gilbert and Nancy Lynch, ACM SIGACT News 33(2), 2002, 51–59. The proof that under partition a service gives up consistency or availability. Your conflict copy is that trade-off, itemised. dl.acm.org