TRICKYwalkthrough
Conflict Resolution
Two engineers fly from San Francisco to Tokyo, both editing the same design doc offline for 11 hours. They land, connect to Wi-Fi, and both devices sync simultaneously.
The constraint: we must never silently discard a user's work. The naive approach, Last Writer Wins (LWW), violates this constraint by overwriting one person's 11 hours of edits.
“What happens? Conflict resolution is the hardest part of any sync system.”
We chose a fork-and-surface strategy (not LWW, not OT) because it guarantees zero data loss for any file type. The server detects the conflict via version vector comparison: if device A's edit has parent version 5 and device B's edit also has parent version 5, but the server is at version 6 (from A's sync), then B's edit is a conflict.
We store both versions and rename the losing copy to 'filename (conflicted copy - device name - date)'. The user sees both files and decides how to merge.
Trade-off: fork-and-surface creates user-visible clutter (conflict files), but data loss is the alternative. Google Docs avoids this with Operational Transformation (OT), merging character-level edits in real time.
But OT requires an always-online server and does not work for binary files like images or compiled assets. What if the interviewer asks: 'Why not CRDTs?' CRDTs (Conflict-free Replicated Data Types) allow automatic merging without a central server, but they only work for specific data structures (counters, sets, text).
For arbitrary binary files, CRDTs have no general solution.