# Design a Mobile File Sync System: Beyond Dropbox

Source: https://www.techinterview.org/post/3233475071/design-mobile-file-sync-system/
Updated: 2026-05-05 · techinterview.org

"Design a file sync system on mobile" is a classic system design topic that gets harder as you dig in. Every byte uploaded is a byte the user pays for; every conflict is a UX nightmare; every sync error is a bug report. The interview tests whether you understand chunked uploads, deduplication, delta sync, and the messy reality of files changing on multiple devices.

## Functional requirements

- Sync files between mobile, desktop, and web

- Detect changes locally and upload

- Detect changes remotely and download

- Resolve conflicts when same file is edited on multiple devices

- Selective sync — choose which folders to sync to mobile

- Offline access to recently used files

## Architecture

Three components: **scanner**, **uploader**, **downloader**.

## Detecting local changes

iOS: NSFileCoordinator and presented documents. Android: file observers. Both have limitations on background detection.

Pragmatic: maintain a local index (path → metadata). On app foreground, walk the synced folder, compare against index, find adds/changes/deletes.

## Chunked uploads

Each file is split into chunks (typically 4–16 MB). Each chunk:

- Hashed (SHA-256)

- Uploaded individually with retries

- Stored once at the server (deduplication across users)

For an 8GB video, this means 1000+ chunks. Resumable: if upload fails at chunk 500, restart from chunk 500.

## Deduplication

Same file uploaded by two users → same chunks → stored once.

Caveat: privacy implications. Naive content-addressable storage leaks "this file exists in the system" to anyone who can compute hashes. Real systems use convergent encryption or per-tenant namespaces to mitigate.

## Delta sync

For changing files (a 100MB document where 1MB changed), upload only the changed chunks.

Algorithms: rsync-style rolling hash; Content-Defined Chunking (CDC) with FastCDC. Each chunk boundary is a function of content, not fixed offset, so insertions in the middle do not shift all subsequent chunks.

## Conflict resolution

Same file edited on two devices simultaneously:

- **Last writer wins:** simple, sometimes loses work. Inappropriate for documents.

- **Conflict copy:** create "filename (Conflicted copy from Device A).docx." User picks. Common.

- **Three-way merge:** works for text. Useless for binary.

Most file sync products use conflict copies. They are visible (user notices) and lossless (both versions kept).

## Selective sync on mobile

Mobile devices have limited storage. Two strategies:

- **Folders only:** user picks folders to sync

- **On-demand:** all files visible (placeholder), download on tap

Modern UX is on-demand with smart caching of recently accessed files.

## Offline access

Files marked "Available offline" are eagerly synced and kept on the device. Other files are placeholders. Tap downloads. LRU eviction frees space when low.

## Background sync

iOS: URLSession background config + background app refresh. Limited budget.

Android: WorkManager with constraints (charging + Wi-Fi for big files).

Don't aggressively sync in the background — battery and data costs add up.

## Frequently Asked Questions

### How do you handle a 50GB folder being synced for the first time?

Stream uploads at the user's discretion (only on Wi-Fi, etc.). Pause-resume across days if needed. Show progress prominently.

### What about end-to-end encryption?

Encrypt chunks with a key derived from the user's passphrase before upload. Server stores ciphertext only. Tradeoff: deduplication across users is no longer possible.

### How do you sync metadata (rename, move) without re-uploading?

Metadata operations are separate from chunk uploads. A rename is a metadata-only update.