!This gives away every stage. For a clean attempt, practise it first, then come back.

Before we start

Think about working on a presentation for a college project. You edit it on your laptop, your teammate edits it on theirs, and later you open it on your phone on the bus. Somehow everyone ends up with the latest version, and if two of you changed it at the same time, nothing disappears.

That’s file sync. The hard parts are: moving as little data as possible (files can be huge), keeping many devices up to date, including ones that were offline for days, and handling two people editing the same file without anyone losing work.

Same order as always: requirements, quick maths, data and API, a design that grows, then deep dives.

Minutes 0–5Requirements

Functional requirements

1. Upload and download files and folders.
2. Changes sync automatically to all of a user’s devices.
3. Edits made offline sync when the device reconnects.
4. Share folders with other people.
5. Restore earlier versions for up to 30 days.

Out of scope: live co-editing, and syncing directly between devices on the same Wi-Fi.

Non-functional requirements

1. Never lose a file.
2. Never silently overwrite someone’s edits.
3. Efficient: only upload the parts of a file that changed.
4. Fast: changes reach other online devices within seconds.
5. Big files work: a 50 GB upload survives dropped connections and resumes.

Minutes 5–10Back-of-the-envelope estimates

Two conclusions. Storage is the biggest cost, so file bytes belong in object storage, stored once. And uploading only changed parts cuts traffic about ten times, so we need a way to know which parts changed.

Minutes 10–15Core entities and the API

Core entities

• Chunk: a piece of a file, about 4 MB, named by its fingerprint (a hash of its contents). Identical pieces have identical names.
• File and version: a file is a path in a folder. Each version is simply a list of chunk fingerprints.
• Namespace: a folder space that devices follow, like “my files” or a shared folder.
• Change log: an ordered list of changes in a namespace, each with a number.
• Device cursor: how far each device has read in each change log.

The API

Notice the upload URLs. They’re signed links straight to object storage, so the file bytes never pass through our own servers. Lesson 2.3 explains signed upload links.

Minutes 15–25The design, built up

Stage 1Upload whole files to a server

It works for small files. But change one word in a 200 MB presentation and you upload 200 MB, then your phone downloads 200 MB. And one server’s disk can’t hold 500 petabytes.

Stage 2Chunks in object storage, metadata in a database

Watch the difference for one small edit:

Because chunks are named by their content, two identical chunks are stored once, whoever uploaded them. That’s where the 30% saving comes from.

Stage 3Sync: a change log, cursors and nudges

The nudge carries no data. If one is lost, the device simply catches up next time it checks. That keeps the notification service simple and makes lost messages harmless.

Stage 4Versions, conflicts and cleanup

Checking the design against the requirements

Deep diveUploading only what changed

Bad solutionUpload the whole file every time

Simple, and wasteful. A small change to a large file costs the whole file in both directions, for every device.

Good solutionFixed-size chunks

Split files into 4 MB chunks and fingerprint each. Only chunks with new fingerprints are uploaded. Dropbox has described using 4 MB blocks this way. But there’s a catch: insert a few bytes near the start of a file, and every chunk boundary after that shifts, so every later chunk looks new.

Great solutionChunk boundaries chosen by the content

Instead of cutting every 4 MB exactly, cut where the content itself matches a pattern, found by sliding a small window over the data and hashing it as you go (a rolling hash). An insertion then only changes the chunks around it, and later boundaries line up again, so they keep their old fingerprints. It’s more complex, but much better for files that get edited in the middle.

Deep diveTwo people edit the same file

Bad solutionLast write wins

Whoever syncs second replaces the first person’s version. Someone’s work vanishes without a word, the one thing the interviewer said must never happen.

Good solutionReject commits that started from an old version

Each commit includes the version it was based on. The first person’s commit, based on version 41, succeeds and becomes version 42. The second person’s commit is also based on 41, but the file is now at 42, so it’s rejected.

Great solutionReject, then keep both as a conflicted copy

The second device doesn’t just fail. It saves its version under a new name, like “plan (Meera’s conflicted copy).docx”, and syncs that. Both versions now exist everywhere, nothing is lost, and the people involved decide how to merge. This is what Dropbox does. Merging automatically would require understanding every file format, which is why live co-editing is a different product.

Deep diveCatching up after a week offline

Deep diveStoring identical files once

Deep diveDeleting safely

The complete architecture

Here’s everything together: the full design from the last stage, with every part we added along the way. If you only remember one picture from this question, make it this one.

How one request travels through it:

1. You save a file. The sync client on your laptop splits it into chunks of about 4 MB and works out a fingerprint (hash) of each.
2. It asks the metadata service which of those chunks the server doesn’t have yet. Usually only one or two are new.
3. It uploads only the missing chunks, straight to object storage, using signed upload links. Our servers never carry the file bytes.
4. It commits the new version: this file is now this list of chunks, based on version 41. If someone else changed the file since 41, the commit is rejected and the client saves a conflicted copy instead.
5. The commit adds an entry to the folder’s change log, and the notification service nudges your other devices over their open connections.
6. Each device asks for changes since its cursor, downloads any chunks it’s missing, and rebuilds the file. Offline devices do the same when they reconnect.

How this answer gets scored

Interviewers don’t tick boxes, but their notes on this question tend to land on the same few moments. Here’s what each one sounds like from the other side of the table.

What the left column has in common: every choice points back to a requirement or a number from earlier. If you can say where each box came from, the interviewer will notice.