Mobile Backup Sync Conflict Resolver

Edit offline

Connectivity

Merge strategy

Vector clock A

[0,0]

Vector clock B

[0,0]

Conflicts resolved

Fast-forward syncs

Sync log

Ready. Edit both devices while offline, then reconnect.

How it works

Each device keeps a version vector [cA, cB] — one counter per device. Editing locally increments only that device's own counter, so the vector records causal history, not wall-clock time.

dominates(X, Y): every component of X ≥ Y, and at least one is strictly greater
X dominates Y  → Y is stale, fast-forward it to X
neither dominates → edits are concurrent → CONFLICT

Fast-forward — if one device's vector clock dominates the other's, no data was lost; the stale replica simply adopts the newer state.
Vector-clock conflict — if neither vector dominates, both devices made an edit the other never saw. That is a genuine concurrent write, not a bug.
CRDT merge — the shared counter is a G-Counter: each device's contribution is tracked separately and merged by taking the element-wise max, so it never loses an increment. The color field is a multi-value register: on conflict both concurrent values are blended into the merged state instead of discarding one.
Last-write-wins — instead of merging, the edit with the later physical timestamp overwrites the other. Simpler, but silently drops data — and if device clocks skew, it can even discard the causally later edit.

Real-world relevance: this is the same trade-off behind CouchDB/Dynamo-style version vectors and CRDT libraries such as Automerge or Yjs used in offline-first mobile apps.

⚠ Couldn't start the simulatorCanvas 2D isn't available in this browser.