skip to content

When a laptop and a phone edit the same file offline in a cloud-drive service, how does the server detect the conflict and settle it?

level: middleimportance: must knowfreq 75%

answer

  1. compare-and-set on commit
  2. which version was this edited from
  3. same hash is not a conflict
  4. opaque bytes cannot be merged
  5. keep both, name the device

basics

~20 s

Each upload names the base revision it was edited from, and the server commits only if that still matches the current revision. A losing upload is kept as a conflicted copy beside the original unless the format allows a safe automatic merge.

solid answer

~50 s

Every file has a server revision, and every upload says which revision it was edited from. The server commits as a **conditional write**: if the base equals the current revision, the upload becomes the next revision; otherwise it is a conflict. So if both devices started from `r5`, whichever syncs first becomes `r6`, and the second arrives with base `r5` while the server holds `r6`. For opaque formats (office documents, images, archives) the server cannot merge, so it keeps both: the second upload is saved as a **conflicted copy** named with the device and date, and both files reach every device through the journal. For formats with understood structure, such as plain text where a three-way merge against `r5` finds no overlapping changes, an automatic merge is possible. What it must never do is silently overwrite based on arrival order or device clocks, which throws away a day of offline work. Two uploads with identical content hashes are not a conflict.

code

http · 8 lines
http
PUT /files/f_91/content HTTP/1.1
If-Match: "r5"
Content-Type: application/octet-stream

<new bytes>

HTTP/1.1 412 Precondition Failed
ETag: "r6"

go deeper

for a junior

Recall that each upload says which version it started from, and that a mismatch means someone else changed the file first.

for a middle

Explain the compare-and-set commit, the identical-hash shortcut, and when a conflicted copy is chosen over a merge.

for a senior

Show judgment on user impact: why silent overwrite is unacceptable, how conflicted copies are named and synced, and how stable file IDs avoid rename conflicts.

for a principal

Weigh product and engineering cost: format-aware merging and version history reduce clutter but add complexity, and the default must favor never losing work.

## The scenario A user opens `budget.xlsx` on a laptop on a train and edits it offline. Later, on a phone, also offline, they edit the same file. Both devices started from the same server version. When each reconnects, the server receives two different new versions of one file. A cloud-drive service needs a rule that **detects** this and a policy that **settles** it without losing anyone's work. ## Detecting: the base-revision check Every file on the server carries a **revision** that increases on each committed change. Each device remembers, per file, the revision it last synced: its **base**. The commit is a compare-and-set: 1. The device uploads the new content and says: this was edited from base `r5`. 2. The server reads the file's current revision. 3. If current equals `r5`, it commits the upload as `r6` and appends a journal entry. 4. If current is anything else, the upload is **stale**: someone else committed in between. The server reports a conflict rather than overwriting. In HTTP terms this is the same idea as a conditional request: the client sends `If-Match` with the entity tag it based its edit on, and the server answers `412 Precondition Failed` when the tag no longer matches. A sync service may express it with its own field, but the mechanism is identical. Because the server is the single authority that assigns revisions for a file, this check is enough to detect concurrent edits in this design. The general theory of detecting concurrency across many replicas is a separate topic; here the point is the practical rule. One refinement: if the stale upload's content hash equals the current revision's hash, both devices made the same change. That is **not** a conflict; the server can treat the second upload as already applied. ## Settling: conflicted copy versus merge Once a conflict is detected, the service chooses between keeping both versions and combining them. | Policy | What happens | Good for | Risk | |---|---|---|---| | Conflicted copy | Second version saved as a sibling file, e.g. `budget (laptop conflicted copy 2026-09-17).xlsx` | Opaque binaries the server cannot interpret | Clutter; user must reconcile by hand | | Automatic merge | Three-way merge of base, current, incoming | Structured formats with non-overlapping edits | Wrong merges if the format is not truly understood | | Overwrite by arrival or clock | Later upload replaces earlier | Almost nothing for user files | Silent loss of real work | **Conflicted copy** is the common default for a general file store because the server does not understand most formats. Key properties: - The original path keeps the revision that won the race, so other devices see no surprise change there. - The copy is a normal new file: it gets its own ID, its own journal entry, and syncs to every device. - Its name tells the user which device and when, so they know where the edits came from. - The device that lost the race learns the new server revision through the journal and updates its local file to match. **Automatic merge** is appropriate only when the service truly understands the format. Line-based text can be merged against the common base when edits touch different lines; if they overlap, fall back to a conflicted copy. Collaborative editors that store operations instead of whole files resolve concurrency inside the document model and rarely surface conflicts at the file level. ## Edge cases worth naming - **Edit and rename at once.** Files are identified by a stable ID, not a path, so a rename on one device and a content edit on another touch different attributes and both apply. - **Repeated conflicts.** A device stuck offline for weeks can produce several conflicted copies; each is still a separate, recoverable file. - **Version history.** Keeping previous revisions lets a user recover even after a merge decision they dislike. - **Upload order.** The device should upload content before asking to commit, so the conditional check is the final, atomic step. ## Summary Detect with a base-revision compare-and-set; settle by keeping both versions unless a trustworthy merge exists. Visible clutter is recoverable; a silent overwrite is not.

  • Why not settle the conflict by comparing the two devices' edit timestamps?
    Device clocks drift, and an offline edit's time says nothing about which change the user wants. Picking the later timestamp silently discards the other edit, which for personal files is the worst outcome because nobody notices until the work is gone. A conflicted copy costs some clutter, but every edit survives and the user decides.
  • When is an automatic merge safe instead of a conflicted copy?
    When the service understands the format and a three-way merge against the common base finds no overlapping edits, for example line-based text where the two devices changed different lines. If edits overlap, or the format is opaque, it must fall back to a conflicted copy, because a plausible-looking wrong merge is worse than two files.
  • Does a rename on one device conflict with a content edit on another?
    Not if files are identified by a stable ID. The rename changes the path attribute and the edit changes the content revision, so the server can apply both. Path-keyed designs turn this into a spurious conflict, which is one reason sync metadata keys files by ID.

It is like two people editing printed copies of the same memo: the office files whichever comes back first as the new version and staples the second on as a labeled alternative rather than shredding it.

saying these in an interview costs you the question

  • Whichever upload reaches the server last should simply win
  • Use the device clocks to decide which edit is newer
  • Two uploads with identical content still need a conflicted copy
  • A file server can safely merge any file type byte by byte
  • Lock the file on the server so offline devices cannot edit it