Design Dropbox

Dropbox-Style Cloud Drive Design

Medium · System Design · Cloud Storage · File Synchronization

Design a single-region backend for a personal cloud drive where users store files and folders that stay synchronized across their laptops and mobile devices. The system must handle a namespace of files and metadata that needs low latency and strong consistency, while the actual file bytes are large, deduplicated, and stored on a separate, throughput-optimized path. A revision commit ties these two paths together by making metadata changes visible and publishing them through an ordered sync stream.

Requirements

Before diving into the design, you clarify the following points with the interviewer.

You: "Should this system handle scenarios where multiple people edit the same file simultaneously in real-time? Or are we limited to a single user per file, where conflicts only happen when that one user's devices go offline and later sync?"

Interviewer: "We're limited to a single user per file. No real-time co-editing. Conflicts arise exclusively when the same user's disconnected devices produce changes to the same file path."

Takeaway: Excluding real-time co-editing means operational transforms and CRDTs are unnecessary. Conflict resolution simplifies to detecting a write based on a stale revision and creating a visible sibling copy rather than merging byte streams.

You: "If two of the same user's devices edit a file while offline and reconnect, should one version win silently, or must both versions be kept so the user can choose?"

Interviewer: "Both versions must be kept. We cannot silently discard one. The losing commit must produce a visible conflict copy for the user to inspect."

Takeaway: Concurrent offline edits cannot be resolved by picking a winner. The system must preserve both user intents and surface the conflict.

You: "When a device comes back online, how does it learn about missed changes? Does the server push events, or does the device poll using a cursor?"

Interviewer: "Push notifications can act as hints to prompt a sync, but they are not the source of truth. A device must always be able to recover the full ordered history via a cursor-based poll. Push events may be dropped or arrive out of order."

Takeaway: Push provides latency improvement, but correctness relies on a replayable pull path that remains functional regardless of notification delivery.

You: "If a large upload is interrupted halfway, must the user restart from the beginning, or should the system support resuming from the point of interruption?"

Interviewer: "Resumable uploads are a firm requirement. Users on unreliable mobile networks should not have to restart large uploads from scratch."

Takeaway: Large file uploads cannot be all-or-nothing operations. The system needs a resumable write protocol and a way to garbage-collect abandoned partial uploads.

You: "Regarding the folder tree and version history, must all devices see the same state instantly, or is a slight delay between devices acceptable?"

Interviewer: "The folder structure, visible file revisions, and conflict outcomes must be strongly consistent within the primary region. Raw file bytes can be eventually consistent, provided the uploading device still sees its own upload immediately after commit."

Takeaway: User-visible metadata truth requires immediate consistency, while byte propagation can tolerate some lag.

You: "Is server-side deduplication a hard launch requirement or an optimization for later?"

Interviewer: "It's a hard requirement. At our target scale—roughly two hundred petabytes of logical data reduced to sixty petabytes physical—storing every upload as a separate copy is cost-prohibitive. Deduplication is integral to the cost model."

Takeaway: Deduplication is fundamental to the cost structure. When content is shared, deletion must respect shared ownership rather than assuming each upload owns its own bytes.

Functional Requirements

• Users can create, rename, move, list, and delete files and folders within a single personal root namespace.
• Users can upload large files through resumable multipart sessions that tolerate network interruptions.
• Users can download file content using HTTP range requests for partial fetches and resume.
• Authenticated devices can request ordered changes from a sync cursor and apply them idempotently after being offline.
• Concurrent writes to the same file path are resolved by materializing a deterministic conflict copy, preserving both user intents.

Non-Functional Requirements

Architecture overview of the cloud drive system

• Namespace structure, visible file revisions, conflict outcomes, and sync ordering are strongly consistent in the primary region.
• Blob replication may be eventually consistent across replicas, provided the uploading client gets read-your-writes after commit.
• Target p99 latency under 200 ms for list folder, path resolution, and commit revision operations.
• Target p99 latency under 300 ms for upload-session control calls; bulk transfer is throughput-bound.
• Plan for approximately 10 million daily active users, 20k peak metadata writes per second, and 100k peak metadata reads per second.
• Plan for approximately 200 PB logical storage and 60 PB physical storage after deduplication.
• Acknowledged metadata writes are durable on commit; committed chunks target object-store durability of eleven nines.
• All APIs require authentication, per-user namespace isolation, scoped blob access, and rate limits on sync and upload endpoints.
• Server-side deduplication and safe garbage collection are first-class requirements.

Back-of-the-Envelope Estimation

Out of Scope

• Real-time co-editing semantics for a single file (operational transforms, CRDTs).
• Full-text search, preview generation, and media processing.
• Team-sharing graphs, compliance workflows, or enterprise policy management.
• Writable multi-region metadata with merge semantics.
• LAN sync or device-to-device transfer.
• End-to-end encryption where the service cannot inspect content hashes for deduplication.