Katkat

Design a Dropbox-like file storage and sync service

MetaSoftware Engineer · Onsite

Last updated

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.

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).