Dropbox

Assume 800M registered users, 100M daily active users, 2B file change commits per day, an average logical changed payload of 2 MB per commit, a 4 MB maximum block size, and 1.2 changed block references per commit after chunking small and medium files.

Assume deduplication, compression, failed-upload cleanup, and version retention reduce unique physical block ingestion to 40 percent of logical changed bytes. Use a 5x peak multiplier over average for upload and metadata traffic. Assume 50M concurrently connected clients and 2 devices notified per committed change on average.

• Commits: 2B file commits per day divided by 86,400 seconds is about 23,148 commits per second, rounded to 23,000.
• Peak metadata writes: applying a 5x multiplier gives about 115,000 commits per second.
• Logical changed data: 2B commits times 2 MB is 4B MB per day, which is about 4 PB per day.
• Deduplication savings: if only 40 percent becomes unique stored blocks, object storage ingests about 1.6 PB per day instead of 4 PB. That implies about 60 percent savings from duplicate files, repeated blocks, compression, and abandoned upload cleanup.
• Block references: 2B commits times 1.2 block references is 2.4B ordered references per day. At roughly 64 bytes per reference before indexes, block-reference metadata alone is about 154 GB per day raw.
• Version metadata: if each commit stores about 1 KB of path, actor, timestamps, permissions snapshot pointer, and version metadata, 2B commits add about 2 TB per day raw before replication and indexing.
• Notifications: 2B commits times 2 target devices is 4B device notifications per day. 4B divided by 86,400 seconds is about 46,000 notification events per second average, with peaks around 230,000 per second.
• Storage: 1.6 PB per day times 365 days is about 584 PB per year before redundancy. With erasure coding, replication, thumbnails, indexes, and retention, a mature service plans in exabytes.
• Long-poll load: 50M connected clients renewing a long-poll every 60 seconds would create about 833,000 renewals per second if implemented naively, so persistent connections, jitter, and regional notification shards are required.

• file_nodes.namespace_id, parent_folder_id, name supports folder listing and enforces unique names inside a folder.
• file_nodes.namespace_id, latest_rev supports lookup of the current visible file version.
• file_versions.file_id, created_at supports version history and restore.
• file_versions.namespace_id, journal_seq supports delta sync by namespace cursor.
• version_blocks.rev, block_index returns the ordered block list for a file version.
• blocks.block_hash is the primary lookup for deduplication and missing-block checks.
• shares.resource_id and shares.principal_id support permission evaluation and user sharing dashboards.

A namespace contains file nodes and a journal sequence. A file node points to one latest revision, while file_versions stores immutable historical revisions. Each revision has many ordered version_blocks, and each version block points to one immutable block object. Shares attach permissions to files, folders, or namespaces and are evaluated before metadata or block download access is granted.

At large scale, split the logical schema across stores. Metadata can live in Spanner, FoundationDB, CockroachDB, or a sharded relational system because commits need transactions and ordered namespace journals. Block existence and reference metadata fit DynamoDB, Bigtable, or Cassandra keyed by block hash. Actual bytes belong in object storage such as S3, Azure Blob Storage, GCS, or an internal erasure-coded blob store.

Avoid putting object bytes in the metadata database. Also avoid relying on one global transaction for block upload and file commit. The commit only needs to verify that referenced blocks are durably present, then append metadata and journal entries atomically within the namespace.

Chunking determines bandwidth efficiency, deduplication ratio, and client CPU cost. Fixed-size blocks such as 4 MB are simple: a changed 20 MB file becomes about five blocks, and a small edit often affects one block. The drawback is boundary shift. If a byte is inserted near the beginning of a large file, every following fixed block may change even though most content is identical.

Content-defined chunking uses a rolling hash to choose boundaries based on the data itself. It improves deduplication for insertions and shifted content, but it adds CPU cost, more complicated manifests, and variable block sizes. Many interview answers choose fixed 4 MB blocks for operational simplicity, then mention content-defined chunking for workloads where insertions in large files are common.

The client should keep a local block cache and avoid recomputing hashes for unchanged files when reliable filesystem metadata is available. Still, correctness must rely on content hashes, not only timestamps, because clocks and filesystem events can be unreliable.

Each block is named by a cryptographic hash of its bytes. If two users upload the same block, the Block Service can store one physical copy and let multiple file versions reference it. This is powerful for common binaries, shared team files, synced photos, and repeated edits that preserve most blocks.

Deduplication has boundaries. Global dedup maximizes savings but can leak information if an attacker can infer that a block already exists. Safer designs deduplicate within a tenant, within a storage region, or only after authorization checks. The server must also verify uploaded bytes because clients cannot be trusted to claim arbitrary hashes.

Hash collisions are extremely unlikely with SHA-256, but the system should still treat the hash as an integrity check, store block size, and optionally verify stronger content fingerprints for critical paths. Blocks should be immutable once written; a new byte sequence gets a new hash and a new object.

The file tree is not stored as mutable bytes in object storage. It is metadata: namespace, folder hierarchy, file nodes, latest revision pointers, historical revisions, permissions, and journal sequence numbers. A commit should atomically create the version record, attach ordered block references, update the file node, and append a journal event.

The namespace journal is the sync source of truth. A client with cursor 100 asks for changes after 100, receives ordered events, applies them locally, and stores the next cursor. If the cursor is too old because compaction removed old journal pages, the client performs a full rescan of metadata for that namespace.

Restores should not mutate old history. Restoring a prior version creates a new latest revision that points to the old block list. This keeps auditability clear and avoids races with clients that already observed newer revisions.

Delta sync means only changed metadata and missing blocks move over the network. Upload starts with a manifest of hashes, the server returns missing hashes, and the client uploads only those blocks. Download starts with the delta journal, then the client compares the required block hashes against its local block cache.

Clients need a scheduler. User-opened files and small metadata changes should download first. Large media, cold folders, and selective-sync excluded paths can wait. The scheduler should pause on metered networks, resume partial downloads, back off on errors, and avoid monopolizing user bandwidth.

For very large files, block-level resume is essential. A 10 GB file should not restart from zero after a laptop sleeps. The manifest, block hashes, and committed revision give the client a precise checklist of what remains.

The Notification Service improves latency but should not be required for correctness. It tells clients that something changed, usually by namespace and cursor watermark. Clients then call the delta API to fetch authoritative ordered changes.

Long-poll is common because it works through firewalls and mobile networks. A client opens a request that waits until a change occurs or a timeout expires. To scale to tens of millions of clients, shard connections by user or namespace, use jittered reconnects, and keep payloads tiny. WebSockets or HTTP streaming can reduce reconnect churn but add connection management complexity.

If notifications are dropped, clients still converge through periodic delta polling. If duplicate notifications arrive, the cursor makes processing idempotent. This separation prevents the notification layer from corrupting file state.

Concurrent edits are unavoidable because clients work offline. The server compares the client's base revision with the current latest revision. If they match, the commit advances the file. If they differ, the server rejects overwrite-if-current and asks the client to create a conflicted copy or run a merge flow.

A typical default is last writer does not silently win for opaque binary files. Instead, create a filename such as spec conflicted copy from Alice laptop and preserve both versions. For text documents or product-owned collaborative formats, a higher-level merge engine can combine changes, but generic Dropbox-style storage should not assume it can safely merge arbitrary bytes.

Conflicts should be visible in the metadata journal so every device converges to the same files. Users can later delete, rename, or manually merge the conflicted copy.

Alternative one is whole-file storage. It is simple and works for small products, but re-uploading a 2 GB file for a tiny edit is unacceptable at scale.

Alternative two is file-system-level replication with a distributed consensus group per folder. It gives strong semantics for narrow workloads but is too heavy for hundreds of millions of consumer clients that are often offline.

Alternative three is application-specific collaboration, such as a document editor with operational transform or CRDTs. That can merge text edits in real time, but Dropbox must store arbitrary files where the service cannot understand the content safely.

Do not use a generic Dropbox-style file sync system when the product requires real-time multi-user editing of structured documents, low-latency transactional databases, or strict POSIX filesystem semantics across machines. Those require collaboration engines, databases, or distributed filesystems with different consistency and locking models.