Dropbox System Design Interview: File Storage and Sync at Scale
Dropbox has publicly reported more than 700 million registered users and over 18 million paying subscribers. It stores exabytes of customer data. Its most famous infrastructure story is the 2016 migration off Amazon S3 onto its own storage system called Magic Pocket, which Dropbox said saved close to 75 million dollars over the two years following the move (all figures reported by Dropbox and press coverage; treat exact totals as point-in-time numbers that drift over the years).
Designing Dropbox is really about two systems that pretend to be one. There is a metadata service that tracks files, folders, versions, and which chunks make up each file, and there is a block storage service that holds the actual bytes as content-addressed chunks. Files are split into fixed blocks of roughly 4 MB, each block is hashed, and identical blocks are stored once no matter how many users or files reference them. When a large file is edited, only the changed blocks are uploaded, which is called delta sync. A sync and notification service watches for changes and pushes them to every device that has the file, and conflict handling decides what happens when two offline devices edit the same file.
Asked at: Asked at Google, Amazon, Microsoft, Meta, Uber, and most companies that run consumer or enterprise storage and sync products. It is one of the most common file-system design questions because almost every candidate has used Dropbox or Google Drive and can reason about the product behavior.
Why this question is asked
Interviewers like this problem because the obvious answer, just upload the file to blob storage, is wrong in interesting ways. To get it right you have to separate file metadata from file content, split files into chunks so you can deduplicate and resync efficiently, hash blocks to store identical content once, and design delta sync so that editing one page of a 1 GB file does not re-upload the whole gigabyte. On top of that you have to reason about sync across many devices, offline edits, and conflict resolution, plus a notification path that tells idle clients that something changed. It rewards candidates who think about the data model and the sync protocol, not just boxes and arrows.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- Upload and download files of arbitrary size, including very large files up to several GB.
- Automatically sync files and folders across all of a user's devices.
- Support offline edits that sync once the device reconnects.
- Share files and folders with other users, with read-only or read-write permissions.
- Keep version history so users can restore a previous version of a file.
- Deduplicate identical content so the same block is not stored twice.
- Detect and resolve conflicts when the same file is edited on two devices.
- Generate previews and thumbnails for common file types.
- Let clients see near-real-time updates when a shared file changes.
Non-functional requirements
- Very high durability, targeting on the order of eleven nines (99.999999999 percent) so files are effectively never lost.
- High availability for both reads and writes, in the range of 99.9 to 99.99 percent.
- Low sync latency so a change on one device appears on another within a few seconds.
- Bandwidth efficiency: only changed blocks should cross the network on edit.
- Storage efficiency through deduplication and compression.
- Strong consistency for metadata so a client never sees a file pointing at a block that does not exist.
- Security: encryption in transit and at rest, and enforced sharing permissions.
- Horizontal scalability to exabytes of content and hundreds of millions of users.
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Registered users
700M+ registered, ~18M paying
Reported by Dropbox in public filings and press. Paying users drive most active sync traffic.
Total files stored
hundreds of billions of files (estimated)
Derived: if each active user keeps thousands of files, hundreds of millions of active users implies hundreds of billions of file objects. Order-of-magnitude estimate, not an official figure.
Total stored bytes
exabytes (multiple EB)
Dropbox has publicly described its storage footprint in exabytes. Content-addressed dedup and compression reduce the raw byte count that must actually be stored.
Block writes per second
~500K to 1M block operations/sec at peak (estimated)
Derived: hundreds of millions of active devices each syncing periodically, multiplied by average blocks per change, produces a high six-figure to seven-figure block op rate. Estimate for sizing, not an official number.
Metadata QPS
millions of metadata queries/sec at peak (estimated)
Derived: every sync check, list, share lookup, and version read hits the metadata tier, and metadata reads greatly outnumber block writes. Order-of-magnitude estimate.
Average block size
up to 4 MB per block
Dropbox has described splitting files into blocks of up to 4 MB, hashing each block, and storing them content-addressed. This is a real, documented design choice.
High-level architecture
The design splits into two independent services that the client stitches together. The metadata service is the source of truth for structure: users, namespaces (a namespace is a syncable root such as a personal folder or a shared folder), files, folders, versions, and the ordered list of block hashes that make up each file. This lives in sharded relational storage, historically sharded MySQL at Dropbox, because it needs transactions and strong consistency. The block storage service holds the actual bytes. Files are split on the client into fixed blocks of up to 4 MB, each block is hashed with a strong hash, and the block is stored under that hash as its key. Because the key is the content, identical blocks are stored exactly once, which is content-addressed storage and gives free deduplication. A sync and notification service sits between them: clients keep a long-lived connection or long-poll it, and when metadata changes for a namespace the service pushes a signal so the client pulls the new metadata and then fetches only the blocks it is missing. Uploads go blocks-first to block storage, then a metadata commit records the new file version pointing at those block hashes, so metadata never references bytes that are not durably stored. Delta sync falls out of this: on edit, the client re-chunks, compares hashes, and uploads only blocks whose hash changed.
In a real interview, sketch this on the whiteboard before diving into any single box.
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
Client sync engine
Runs on desktop and mobile. Watches the local file system, splits files into up to 4 MB blocks, hashes each block, maintains a local database of file state and block hashes, decides which blocks are new, uploads changed blocks, commits metadata, and applies remote changes it learns about from the notification service.
Metadata service
Stores users, namespaces, files, folders, versions, and the block-hash list per file version in sharded relational storage. Serves list, resolve, and commit operations transactionally. This is the authority on what a file is; it never stores the bytes themselves.
Block storage service
A content-addressed store keyed by block hash. Given a hash it returns the block; given a block it stores it once and returns success. Handles replication, erasure coding, and durability. This is Dropbox's Magic Pocket in the real system.
Sync and notification service
Holds long-poll or persistent connections from clients per namespace. When a metadata commit changes a namespace, it notifies subscribed clients so they pull the delta quickly instead of polling on a slow timer.
Sharing and permissions service
Manages shared namespaces, membership, and read or write permissions. Adding a user to a shared folder attaches that shared namespace to their account so it syncs to their devices under the same block model.
Preview and thumbnail service
Asynchronously renders previews and thumbnails for images, documents, and video so the web and mobile UIs can show content without downloading the full file. Runs off a queue triggered by new file versions.
Data model
Pick the right store per table. Justify each choice with the access pattern, not by reflex.
usersuser_idemaildisplay_namestorage_quota_bytesstorage_used_bytescreated_atOne row per account. storage_used_bytes is maintained as blocks are added or removed from the user's namespaces.
namespacesnamespace_idowner_user_idtyperoot_namecreated_atA namespace is a syncable root. type distinguishes a personal root from a shared folder. Sharing works by attaching a namespace to multiple users.
filesfile_idnamespace_idpathcurrent_version_idis_folderupdated_atRepresents a logical file or folder within a namespace. Points at the current version. path plus namespace_id is unique.
file_versionsversion_idfile_idblock_listsize_bytescontent_hashcreated_by_device_idcreated_atImmutable. block_list is the ordered array of block hashes that reconstruct this version. Old versions are retained for history and restore.
blocksblock_hashsize_bytesref_countstorage_locationcreated_atContent-addressed. block_hash is the primary key. ref_count tracks how many file versions reference the block so it can be garbage collected when it reaches zero. The bytes live in block storage, not in this row.
sharesshare_idnamespace_idgrantee_user_idpermissioninvited_bycreated_atOne row per user granted access to a shared namespace. permission is read or write.
devicesdevice_iduser_idplatformlast_sync_cursorlast_seen_atTracks each device and its sync cursor so the server knows how far behind a device is and what deltas to send.
Deep dives
These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.
Why chunk files into blocks instead of storing whole files
Storing a file as one blob is simple but wastes bandwidth and storage the moment the file changes. If a user edits one paragraph of a 1 GB document and you store whole files, you re-upload and re-store a full gigabyte. By splitting the file into fixed blocks of up to 4 MB and hashing each block, you can compare block hashes between the old and new version and touch only the blocks that changed. Fixed-size blocks are simple and fast to compute. Some systems use content-defined chunking with a rolling hash so that inserting bytes at the start of a file does not shift every subsequent boundary, at the cost of more CPU. Dropbox has described using blocks of up to 4 MB, which keeps the block index small while still giving useful dedup and delta granularity.
Content-addressed storage and deduplication
Each block is stored under the key equal to its hash. This is content addressing. The direct benefit is deduplication: if two users upload the same PDF, or the same file appears in a hundred shared folders, the underlying block is stored exactly once and every file version just references the same hash. A reference count per block tracks how many versions point at it, and a block is only eligible for garbage collection when its count drops to zero. Content addressing also gives cheap integrity checking, because you can re-hash a block on read and confirm it matches its key. The tradeoff is that dedup across users has privacy and security implications, discussed below, and that you need a strong hash to make accidental collisions effectively impossible.
Delta sync: uploading only what changed
Delta sync is the payoff of chunking plus content addressing. When a file changes, the client re-chunks the new version, hashes each block, and diffs the new block-hash list against the old one it has cached locally. It asks the server which of the new hashes it already has, uploads only the blocks the server is missing, then commits a new file_version whose block_list is the full new ordered list. So a small edit to a large file uploads a few kilobytes of blocks plus a small metadata commit, not the whole file. Download works the same way in reverse: a device learns the new block_list, compares it to the blocks it already holds locally, and fetches only the missing ones.
Separating metadata from block storage
Metadata and bytes have opposite needs, which is why they are different services. Metadata is small, highly relational, and needs transactions and strong consistency: a commit that creates a new version and updates the current pointer must be atomic, and a client must never see a version that references a block that is not yet durable. That fits sharded relational storage. Block bytes are large, immutable once written, and need extreme durability and cheap capacity rather than transactions. That fits a purpose-built content-addressed store. Splitting them lets each scale on its own axis, lets you dedup at the block layer without the metadata layer knowing, and lets you commit metadata only after blocks are safely stored. The write order is always blocks first, then the metadata commit.
Sync conflict resolution across devices
Conflicts happen when two devices edit the same file while at least one is offline, so neither saw the other's change before committing. The metadata service uses each namespace's version history to detect this: when a device tries to commit a new version whose parent is no longer the current version, the server knows the base has moved. Dropbox's product behavior is to not silently overwrite. It keeps both versions and creates a conflicted copy, typically named with the device or user and a timestamp, so no edit is lost and a human decides which to keep. This is safer than pure last-writer-wins, which is simple but can destroy work. For fine-grained collaborative editing, a different model such as operational transforms or CRDTs is needed, which is why Google Docs style co-editing is a separate problem from file sync.
The notification and long-poll service
You do not want millions of idle clients polling the metadata service every few seconds; that is wasteful and adds latency. Instead each client holds a long-poll request or a persistent connection to a notification service, subscribed to the namespaces it cares about. The connection stays open and cheap until something changes. When a commit modifies a namespace, the notification service signals the subscribed clients, which then make a normal request to the metadata service to pull the delta and fetch missing blocks. This keeps steady-state cost low while still delivering changes within seconds. It is the same pattern behind push-style updates in chat and collaboration products.
Durability and the Magic Pocket migration off S3
Durability is the hard non-functional requirement: losing a customer's file is unacceptable, so the target is on the order of eleven nines. Early Dropbox stored blocks in Amazon S3 while running its own metadata. As scale grew, Dropbox built its own storage system, Magic Pocket, and migrated the vast majority of its data off S3 in 2016. Magic Pocket uses replication and erasure coding across multiple facilities to hit high durability at lower cost than paying a cloud provider per gigabyte. Dropbox reported the move saved close to 75 million dollars over the following two years. The lesson for an interview is that owning storage only makes sense at very large, predictable scale where you can amortize the engineering and hardware; below that, managed cloud storage is the right call.
Trade-offs to discuss
Every senior interviewer expects you to surface at least 3 of these. Pick the decisions, state the alternatives, and justify your choice.
Own storage (Magic Pocket) versus managed cloud storage
Running your own content-addressed store cuts per-gigabyte cost dramatically at exabyte scale and lets you tune durability and layout, but it needs a large team and years of hardware investment. It only pays off past a scale most companies never reach. Below that, S3 or GCS is faster to build on and cheaper in total.
Fixed 4 MB blocks versus content-defined variable chunks
Fixed blocks are simple, cheap to compute, and give a small block index. Content-defined chunking with a rolling hash dedups better when bytes are inserted or removed in the middle of a file, but costs more CPU and complexity. Dropbox chose fixed up-to-4 MB blocks, trading some dedup efficiency for simplicity.
Strong consistency for metadata versus eventual consistency
Metadata is kept strongly consistent so a version never references a missing block and clients never see a torn state. That constrains the metadata store to transactional, sharded relational storage rather than an eventually consistent key-value store, which limits raw write throughput but is worth it for correctness.
Cross-user deduplication versus privacy and security
Deduping identical blocks across all users saves the most storage, but it can leak information: if uploading a file is instant because the block already exists, an attacker can infer someone else already has that exact file. Mitigations include per-user or per-namespace dedup scopes and not exposing timing. The tradeoff is storage savings versus privacy leakage.
Conflicted copies versus last-writer-wins
Keeping both edits as a conflicted copy guarantees no data loss but leaves the user to reconcile manually. Last-writer-wins is simpler and needs no user action but can silently destroy work. For a file sync product, preserving data wins, so conflicted copies are the default.
Client-side chunking and hashing versus server-side
Doing chunking and hashing on the client saves upload bandwidth because the client can skip blocks the server already has before sending anything, and it spreads CPU cost across users' machines. The cost is a heavier, more complex client and reliance on the client to compute hashes correctly, which the server can still verify on receipt.
How Dropbox actually does it
The real Dropbox matches this shape closely. Metadata has historically lived in sharded MySQL, with a large fleet of shards behind a metadata service. Block bytes moved from Amazon S3 to Dropbox's own Magic Pocket storage system in 2016, using replication and erasure coding across facilities for durability and reporting large cost savings versus the cloud. Files are split into blocks of up to 4 MB, hashed, and stored content-addressed with deduplication. On the sync side, Dropbox rewrote its sync engine, replacing the older Python engine with a new one written in Rust called Nucleus, to make the sync logic correct and testable under the enormous number of edge cases that multi-device offline editing creates. The notification path uses long-lived client connections so changes propagate within seconds rather than on a slow poll.
Lessons to study before this interview
If any of these topics are fuzzy, the interviewer will catch it. Each lesson is 15 to 60 minutes with diagrams, code, and a quiz.