A file sync product loses user edits during a conflict. What are the likely design failures?

The candidate failures

• Last-write-wins on whole files, where "last" is decided by a timestamp from a client whose clock is wrong. Device clocks are unreliable in both directions, so the surviving version may be the older edit.
• Silent resolution. The system picks a winner and discards the loser with no record and no notification. User-authored content should never be discarded silently — it may be superseded, renamed, or flagged, but the user must be able to recover it.
• Sync state and file content stored separately without atomicity, so a crash between writing content and updating state leaves a file the system believes is synchronised and is not.
• No causal tracking. Without version vectors or equivalent, the system cannot distinguish a genuine concurrent edit from a linear sequence, so it treats ordinary sequential edits as conflicts and vice versa.
• Directory-level operations treated as atomic when they are not — a move plus an edit arriving separately can lose the edit.

What the design should do instead

• Preserve both sides. Conflict copies are unglamorous and they are the only approach that never loses work.
• Track causality explicitly, so concurrency is detected rather than inferred from timestamps.
• Content-addressed storage of file versions, making a discarded version recoverable and deduplicating identical content.
• Atomic local state transitions, so an interrupted sync is resumable rather than ambiguous.
• Server time as the ordering authority where an ordering must be established, never client clocks.

The measurement that would have caught it

Conflict rate and resolution outcome as monitored metrics, segmented by resolution type. A rising rate of silent discards is invisible without instrumentation, and by the time users report it the pattern is months old and the evidence is gone.