##### Question Design a cloud file storage and synchronization service like Dropbox / Google Drive. The system should let users store files and folders, keep them in sync across multiple devices, share them, and recover previous versions — at internet scale (hundreds of millions of users). Work through the following: 1. **Core sync** — Upload/download files and folders; client-side folder monitoring (inotify/FSEvents/ReadDirectoryChangesW); propagate changes across all of a user's devices. 2. **Large-file handling** — Chunked, resumable uploads/downloads; delta sync so an edit only transfers the changed bytes; deduplication and compression. 3. **Versioning & restore** — Per-file version history, tombstones for deletes, and the ability to restore or undelete. 4. **Conflict resolution** — Detect and resolve concurrent edits from multiple devices (including offline edits replayed on reconnect). 5. **Offline support** — Offline-first client with a local index and a write-ahead journal of pending operations. 6. **Sharing & permissions** — Share folders/files with specific users or groups, and via capability/share links with scope and expiry; ACLs with inheritance. 7. **Change notification** — Push change events to devices in near real time (APNs/FCM/WebPush) with long-poll/WebSocket fallback. 8. **Encryption** — In transit and at rest; discuss server-side encryption (SSE) vs. client-side / end-to-end encryption (CSE) and the dedup trade-offs of each. 9. **Mobile constraints** — Battery-, network-, and background-execution-aware scheduling; selective / on-demand sync. 10. **Quota & billing** — Logical vs. billed (post-dedup/compression) bytes, enforcement, and usage accounting. 11. **Architecture & data model** — Clients and sync engine, metadata service, blob/object storage and CDN; model files, chunks, versions, ACLs, tombstones, and a change journal. 12. **Consistency model** — What guarantees do readers and writers get within and across devices? 13. **Scale & operations** — Sharding/partitioning, hotspots, observability, disaster recovery, and online migrations/backfills (e.g., changing chunk size or rotating crypto keys). Out of scope: real-time collaborative editing (Google Docs / OT/CRDT co-editing).

Design a Dropbox-like file storage and sync service evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Onsite rounds at Meta.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Meta during technical interviews.

Design a Dropbox-like file storage and sync service

Design a cloud file storage and synchronization service like Dropbox / Google Drive. The system should let users store files and folders, keep them in sync across multiple devices, share them, and recover previous versions — at internet scale (hundreds of millions of users).

Work through the following:

Core sync — Upload/download files and folders; client-side folder monitoring (inotify/FSEvents/ReadDirectoryChangesW); propagate changes across all of a user's devices.
Large-file handling — Chunked, resumable uploads/downloads; delta sync so an edit only transfers the changed bytes; deduplication and compression.
Versioning & restore — Per-file version history, tombstones for deletes, and the ability to restore or undelete.
Conflict resolution — Detect and resolve concurrent edits from multiple devices (including offline edits replayed on reconnect).
Offline support — Offline-first client with a local index and a write-ahead journal of pending operations.
Sharing & permissions — Share folders/files with specific users or groups, and via capability/share links with scope and expiry; ACLs with inheritance.
Change notification — Push change events to devices in near real time (APNs/FCM/WebPush) with long-poll/WebSocket fallback.
Encryption — In transit and at rest; discuss server-side encryption (SSE) vs. client-side / end-to-end encryption (CSE) and the dedup trade-offs of each.
Mobile constraints — Battery-, network-, and background-execution-aware scheduling; selective / on-demand sync.
Quota & billing — Logical vs. billed (post-dedup/compression) bytes, enforcement, and usage accounting.
Architecture & data model — Clients and sync engine, metadata service, blob/object storage and CDN; model files, chunks, versions, ACLs, tombstones, and a change journal.
Consistency model — What guarantees do readers and writers get within and across devices?
Scale & operations — Sharding/partitioning, hotspots, observability, disaster recovery, and online migrations/backfills (e.g., changing chunk size or rotating crypto keys).

Out of scope: real-time collaborative editing (Google Docs / OT/CRDT co-editing).

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?