Design a file synchronization service

01Synchronize saved revisions without losing offline edits

Two laptops share budget.xlsx. Both start from revision 12, then edit while one is offline. The service must eventually distribute saved work without allowing the last upload to erase a change its author never saw. File synchronization therefore needs more than byte copying: it needs stable file identity, saved revisions, change discovery and a conflict policy.

Support files and folders, uploads, downloads, rename, deletion, shared workspaces, offline edits and retained versions. A workspace is a shared set of files and membership rules. Keep its metadata changes within one transaction domain for this interview. A stable file ID survives a rename; the pathname tells us where that file currently appears.

Use conflict copies for concurrent binary edits. Automatically merging arbitrary spreadsheets or images is outside scope. Distinguish saved locally, upload pending, committed on the server and applied on another device. A successful server commit does not mean an offline laptop has already received the file. Limit files to 1 GiB and declare a history-retention window; indefinitely disconnected clients cannot depend on a log kept for only a month.

Clarify whether concurrent offline edits may overwrite each other, how long history must remain recoverable, and what delay is acceptable for an online second device. This design preserves conflicts and separates a change notification from completion of byte transfer.

02Functional requirements

Agree on these supported actions before selecting components.

1. Manage a shared file namespace. Create files and folders, rename and delete them, and authorize access through workspace membership. File identity remains stable through a rename.

2. Synchronize across devices. Upload and download saved revisions, let offline devices catch up, and show local, pending, server-committed and locally-applied states distinctly.

3. Preserve concurrent edits. Retain both users’ work when an offline edit conflicts with a newer saved version, and make the conflict visible instead of silently overwriting either edit.

4. Recover and restore. Resume interrupted operations, retrieve retained versions and resynchronize safely when a device cursor is older than the change history.

03Non-functional requirements

Use these as illustrative interview assumptions to agree with the interviewer. Numerical targets require measurement; they are not claims about an existing product or a proven implementation. p95 (the 95th percentile) means 95% of measured operations finish within the stated time.

1. Workload and file limits. Use 100 billion current files, approximately 10 PB of current logical bytes and a peak of about 28,935 metadata commits/s. Limit each file to 1 GiB; retained revisions add capacity beyond those current-file totals.

2. Metadata latency and discovery. Target regional p95 metadata responses within 200 ms and p95 committed-change discovery within five seconds for connected devices during normal operation. Completing a large download depends on file size and bandwidth and is not covered by the five-second target.

3. Revision integrity and durability. A committed revision must name complete protected chunks and survive a process restart or one storage-node failure within the region. Concurrent commits cannot silently lose either author’s accepted work.

4. Bounded retained history. Choose 30 days of prior revisions and change-log history for this exercise. Devices beyond that history window must preserve local pending edits and recover from a consistent snapshot instead of skipping directly to the newest cursor.

5. Workspace isolation. Authorize upload, commit, revision reads and downloads. Chunk reuse must not disclose or grant access to another workspace’s private content.

6. Recovery under overload. Bound transfer concurrency and spread reconnect retries. If metadata cannot safely commit, clients retain pending local work and must not report synchronized success.

04Commit a whole file, then let another device catch up

Start with one metadata database, durable file storage and a client that periodically asks for changes. Laptop A uploads an immutable copy of its saved file. After verifying the bytes, the server checks that A edited revision 12 and the current file is still revision 12. In one metadata transaction it records revision 13, makes it current and appends a change entry.

Laptop B asks for changes after its last saved position. It learns that file f42 now has revision 13, downloads that immutable version to a temporary location, verifies it and replaces its local copy. It records progress so a restart can resume. If B has unsent edits, it preserves them instead of blindly replacing the file.

The local client must capture a stable byte version before uploading. Reading a live file while another application rewrites it can mix two saves. A staging copy or suitable filesystem snapshot makes the uploaded bytes correspond to one captured revision.

This whole-file baseline is slower for large repeated edits, but it already establishes the essential rules. Uploading bytes does not make them current; the metadata commit does. Polling may delay discovery, but missed network notifications cannot lose a committed revision.

05Count changed bytes, metadata and online devices separately

Assume 500 million accounts, 200 files per account and 100 KB average file size. That is 100 billion current files and 10 PB of logical current content. At an illustrative 1 KB of file metadata, metadata alone reaches 100 TB before indexes and replicas. Old revisions add storage beyond the current-file total.

For 100 million daily active users making five committed changes each, average commits are 500M / 86,400 ≈ 5,787/s. A fivefold peak is about 28,935/s. If a change uploads 200 KB on average, mean changed-byte ingress is approximately 1.16 GB/s. Downloads depend on how many other devices actually receive the change.

The byte estimates motivate independent object storage; the metadata estimate motivates partitioning. Connection work motivates notification hints. These are different pressures. Do not claim a fixed deduplication saving: small files may change entirely, and compressed formats can change many bytes after a seemingly small edit.

06Name the base revision and the recovery cursor

Begin an upload with the file identity, expected base revision and a client-generated request identity.

Start-upload information for the running example

File ID:                f42
Expected base revision: 12
Request ID:             edit-77

A retry keeps edit-77 and the same payload. The server returns an upload session; completing byte transfer is distinct from committing a new current revision.

A conflict returns the preserved conflicting revision or conflict-file identity. Repeating the same operation returns that outcome, rather than creating another conflict copy. A restore creates a new revision from retained history; it does not rewrite the past.

A cursor identifies how far a device has applied committed changes. If its position is older than retained history, return a clear resynchronization response. The client obtains a consistent file snapshot and its matching log position, preserves local pending work, and resumes after that boundary. Jumping straight to the newest cursor would miss deletions and renames.

07Separate identity, revision and byte layout

The metadata records separate the current directory entry, saved content and the history other devices must apply.

Membership and request-result records participate in the relevant metadata decisions.

Folder browsing needs (workspaceId, parentId, name). Device catch-up needs (workspaceId, sequence). File lookup uses stable file ID. A name-based shard key would complicate renames; hashing every file independently would complicate workspace-wide ordering and atomic folder changes. Partition independent workspaces first so their local checks remain understandable.

A delete leaves a tombstone: a retained deletion record that an offline device can observe. Merely removing the row would make absence indistinguishable from a change the client never learned about. Retained old revisions still need their chunks, so cleanup must check more than the current revision.

The client has its own durable local journal for pending uploads, accepted revisions and in-progress downloads. It is part of the system, not an optional cache. A restart must not forget work just because the server is reliable.

08Preserve both edits when the expected revision changed

Laptop A and laptop B both edit revision 12. B's metadata transaction checks currentRevision=12 and commits revision 13. A arrives later with the same expected base. Its check now fails because currentRevision is 13. The server preserves A's content as a conflict copy and records that outcome without replacing B's accepted head.

The compare and update must happen atomically. A separate read followed by an unconditional write allows both clients to pass the check and overwrite each other. Client timestamps do not solve the problem: clocks differ, and being later does not establish an intention to discard an unseen edit.

A conflict copy is a real saved object. Its bytes, metadata and change event must survive just like a normal revision, so other devices can discover it and the user can resolve it. Recheck write permission at publication; a long-running upload must not bypass a membership revocation by calling its output a conflict.

Within one workspace, commit each revision update and its change-log position together, in order. A device must not advance beyond an earlier change that can still commit later. This is why a counter allocated before commit is not automatically a safe synchronization cursor.

09Transfer changed chunks after the basic revision rule works

Suppose a 9 MiB file is split into 4 MiB, 4 MiB and 1 MiB chunks. Only the middle chunk changes.

This transfers 4 MiB instead of 9 MiB for that upload, saving about 56% in this particular example.

Chunk identities include a verified content checksum and size. Scope reuse to content the workspace is authorized to access; a global “does this hash exist?” endpoint can reveal another customer's private content. The manifest is committed only after every referenced chunk exists and is protected from deletion.

Protect chunks needed by an active upload, then transfer that protection to saved-revision references when commit succeeds. Cleanup first marks an unreferenced chunk as unavailable for future publication before deleting its bytes. A stale scan finding no reference is insufficient if an upload can start using the chunk afterward.

Fixed-size chunks are straightforward and provide bounded retry units. An insertion near the start may shift later boundaries, reducing reuse. Content-defined chunking chooses boundaries from content patterns and can improve that workload, at additional CPU and implementation cost. Patches inside changed chunks are another later optimization; neither is necessary to explain the first correct sync service.

10Use notifications to prompt durable catch-up

Millions of periodic empty polls create work even when nothing changes. A notification gateway can keep a persistent connection or long poll and send a small “workspace changed” hint. The device still reads the durable change log using its cursor. A lost hint delays discovery until reconnect or another poll; it does not erase history.

Separate bulk byte transfer from small metadata operations, with independent concurrency and bandwidth limits. A slow 1 GiB upload should not prevent another user from renaming a folder. Cache popular chunks and manifests only when measured reuse justifies their memory cost; a large chunk displaces far more cache space than one metadata row.

Distribute workspaces across replicated metadata groups. This scales independent workspaces while keeping their conflict checks, directory changes and change history within one transaction boundary. One unusually large workspace remains a potential bottleneck; splitting it requires a new ordering and transaction design, not simply a different hash function.

Gateways do not own revisions. They can be replaced and clients reconnect from durable cursors. Spread reconnects with randomized delays and limit concurrent snapshot recovery and downloads during a fleet restart. More connections and faster notifications improve responsiveness only if metadata and byte services can handle the recovery traffic.

Implement the one-node-loss requirement with durable majority commits across three metadata replicas per workspace group in independent regional failure domains, plus chunk storage whose acknowledged writes survive one storage-node loss. Retain the selected 30-day revision/change window and benchmark metadata and change-discovery targets independently of bulk-transfer duration.

11Recover local and server interruptions separately

If a client crashes after uploading chunks but before commit, its local journal and server upload session identify the pending operation. A retry may finish it while the session remains valid. If commit succeeded but its response was lost, edit-77 retrieves the original result and must not create revision 14 accidentally.

A receiving device may crash after replacing the local file but before recording its new cursor. Its journal must recognize the completed replacement and finish the metadata update on restart. Conversely, advancing the cursor before retaining the bytes or a durable recovery plan can permanently skip a change. The local filesystem and the client's metadata database do not automatically share a transaction.

When the server cannot safely accept metadata writes, the client may continue editing locally with pending status. It should not claim synchronization. After recovery, the actual base revision determines whether a conflict exists. An already downloaded file cannot be made secret again by server-side revocation.

Backups must restore metadata, retained revisions and their referenced chunks together. Test an old-version restore after newer revisions and deletion. A healthy current file does not prove that historical chunks still exist.

12Measure synchronized work, not just successful uploads

Measure metadata commit latency, time for connected devices to catch up, conflict rate, transferred bytes per revision and time spent pending. Missing chunks in an accepted revision are an integrity incident; a delayed notification is a different problem. Track old upload sessions and cleanup backlog so temporary bytes do not grow without bound.

Authorize upload, final commit and downloads. Scope transfer credentials to the intended object and operation. Keep filenames and file contents out of broad telemetry. Count retained revisions toward quotas, otherwise repeated overwrites can consume large historical storage while the visible current file stays small.

Cost combines current bytes, version history, replicas, transfers, chunk-reference metadata and client/server CPU. Chunking is worthwhile when saved bytes exceed its lookup and bookkeeping cost. Test a tiny-file workload as well as large files with localized edits.

Exercise concurrent offline edits, a rename during synchronization, an expired history cursor, cleanup racing an upload and mass reconnection. These scenarios test the user's promise that work survives and converges, rather than merely demonstrating that files can cross the network.

13Check the design against the requirements

Use the agreed lists to check the finished design. The tests below still need to establish the targets; a proposed mechanism is not a measured result. FR refers to the numbered functional requirements above; NFR refers to the numbered non-functional requirements.

14Rapid revision

Remember: Compare the saved base before replacing the current revision; an unseen edit must become a conflict, not disappear.

A strong summary follows revision 12 into two offline edits, explains which metadata transaction wins and where the other edit is saved, then shows how a second device catches up. Chunking and notifications are efficiency improvements around that model. Automatic document merging and extremely large shared workspaces require further semantics; they are not solved merely by adding more transfer servers.

Recall the key ideas

Answer from memory before opening each card. Explain why the choice works and what it costs. Revisit missed cards tomorrow.