How Dropbox Rebuilt Its Sync Engine for 700 Million Users

Lucas: If these conversations are useful for what you're building or running, I want to start today with a number that still kind of blows my mind: Dropbox handles about one point two billion file operations per day. That's syncing, uploading, downloading - across seven hundred million registered users. Luna: And that's just the public-facing number. Behind the scenes, their conflict resolution engine has to reconcile what happens when the same file gets edited on three devices at once.

Lucas: Exactly. That's the part I wanted to dig into. Dropbox recently published a really detailed post-mortem - or really, a 'how we rebuilt it' - on their sync engine. And this is a system that's been running since 2007, written in C++, and they decided to rewrite the core in Rust.

Luna: A full rewrite of a production sync engine serving hundreds of millions of users - that's the kind of thing that keeps CTOs up at night. Lucas: Right. And to their credit, they didn't do it all at once. They used a strangler fig pattern - slowly replacing the old sync logic with new Rust-based components while keeping the C++ code running in parallel for years.

The actual migration took about three years from first commit to full cutover. Luna: So let's start with the why. What was broken about the old engine? Lucas: The old engine used a two-way sync model.

Basically, it tracked pairs of folders - your local Dropbox folder and the cloud. It would compare timestamps, checksums, and try to figure out what changed. That works fine when you have one laptop and one phone, but it starts to fall apart with multiple devices, selective sync, and especially with the rise of mobile. Luna: And the failure mode was conflicts.

If two devices modified the same file before either one synced, you'd get a conflict copy - 'conflicted copy.' Which is a user-facing problem, but also a data integrity problem. Lucas: Exactly. Under the old model, the system couldn't merge changes intelligently.

It would just create a duplicate and let the user sort it out. As of 2024, Dropbox was seeing about three hundred fifty million conflict events per day. That's an enormous tax on user trust and on the backend. Luna: So they decided to move to a block-level sync engine.

Instead of treating a file as a monolithic blob, they break it into chunks - blocks - and track each block by its hash. That's content-addressable storage in the classic sense. Lucas: Right. So if you change one paragraph in a hundred-page document, the old system might re-upload the whole file.

The new system only uploads the blocks that actually changed. And because it's hash-addressed, deduplication happens automatically - if two users have the same block, it's stored once. Luna: That's huge for bandwidth and storage costs. But the real magic is in conflict resolution.

How do they merge concurrent edits at the block level? Lucas: They use a data structure called a Merkle tree - specifically a Merkle hash tree - for the file's block index. Every file has a tree of block hashes. When two devices sync, they compare the root hash.

If it's the same, no conflict. If it differs, they walk down the tree to find which sub-tree diverged, and then they can merge at the block level. Luna: So instead of a whole-file conflict, you only get a conflict on the specific blocks that changed. And if the changes are in different blocks, the merge is automatic.

Luna: What happens when two devices change the same block? Do they use CRDTs? Lucas: They do something similar but not exactly a pure CRDT. They use a last writer wins strategy, but with a twist: the system tracks causal history using vector clocks.

So if device A and device B both modify block X, but A's change is causally dependent on B's, the system can detect that and apply both in order. Lucas: If they're truly concurrent - no causal relationship - they fall back to a deterministic merge based on a consistent ordering rule. In practice, they say that over ninety-nine point nine percent of conflicts are resolved automatically without user intervention. Luna: That's a massive improvement.

And it also reduces the number of conflict copies users have to deal with, which is a direct UX win. Lucas: Exactly. And the Rust rewrite played a big role in making the block-level engine performant enough. The old C++ engine had a lot of accumulated technical debt - manual memory management, thread safety issues, and a monolithic architecture.

Rust gave them memory safety without a garbage collector, and the async ecosystem allowed them to handle thousands of concurrent sync operations efficiently. Luna: I've heard that the new engine achieves a median sync latency under two hundred milliseconds for small files. Is that right? Lucas: That's what they reported in their engineering blog.

And that's end to end - from the moment a file changes on one device to the moment it appears on another. Under the old engine, that number was closer to five hundred milliseconds for the same scenario. So it's more than doubled the perceived speed. Luna: Quick honest thing - we can only keep making deep dives like this because a handful of listeners chip in monthly through buy me a coffee dot com slash fexingo.

That literally funds the research and production time. So if you get value from these episodes, consider joining them. Lucas: Yeah, it's a small group that already keeps it ad-free, and it makes a real difference. Anyway, back to the architecture - one of the more interesting design decisions was how they handled the migration of existing users' data to the new block format.

Luna: Right - because you can't just migrate seven hundred million users overnight. They used a gradual rollout where users could opt in to the new engine via a feature flag. Lucas: And the opt-in wasn't binary. They actually had three tiers: old engine, hybrid mode where reads used the new engine but writes still used the old, and full new engine.

That let them catch bugs without risking data loss. Luna: What was the biggest bug they caught during that rollout? Lucas: The most memorable one was a race condition in the block indexing layer. When a file was being synced from two devices simultaneously, the new engine could create duplicate blocks for the same content if the deduplication check happened before the first write completed.

They had to add a distributed lock on the block hash. Luna: That's exactly the kind of edge case that's hard to catch in testing but becomes obvious at scale. So they had to handle that before full rollout. Lucas: And they did.

They also built a canary system that would automatically roll back the feature flag for any user who experienced a data integrity error. Over the three-year migration, they only had to roll back about zero point zero one percent of users - mostly due to very old file formats that the new engine didn't handle perfectly. Luna: One thing I'm curious about: the block-level approach works well for binary files, but what about things like Office documents or collaborative apps where the file format is opaque?

You can't merge blocks if you don't understand the structure. Lucas: That's a great point. For structured file formats, Dropbox actually partners with the application vendors - Microsoft, Google, etc. - to use their own sync APIs.

So for Office documents, they use Microsoft's own sync protocol, which is block-level but application-aware. The Dropbox sync engine handles the binary files and the metadata, but the app-specific sync is delegated. Luna: So the sync engine is really a general-purpose infrastructure layer, not a one-size-fits-all solution. That makes sense.

Lucas: Exactly. And it's worth noting that they also rebuilt the client-server protocol. The old protocol was rest based with polling. The new one uses a persistent gRPC stream with server-sent events.

That reduced the time to detect changes from thirty seconds to under one second. Luna: That's a massive improvement. And it also reduces server load because clients aren't polling every thirty seconds. Lucas: Right.

The engineering team estimated that the new protocol reduced server-side bandwidth by about forty percent because of the elimination of polling overhead and the block-level deduplication. Luna: What about the team structure? How did they organize the rewrite without disrupting the existing product? Lucas: They used a dedicated core infrastructure team - about fifteen engineers - that owned the sync engine.

But they also embedded liaisons from the mobile, desktop, and web teams to ensure the new engine met their needs. And they ran the old and new engines in parallel for eighteen months before cutting over. Luna: So it was a classic 'two-pizza team' with strong cross-functional ties. That's a good pattern for any large-scale infrastructure rewrite.

Lucas: Absolutely. And the key lesson is that they didn't try to rewrite everything at once. They started with the block storage layer, then the conflict resolution, then the protocol, and finally the client libraries. Each piece was tested independently before integration.

Luna: It sounds like the migration took longer but was much safer. I think a lot of CTOs would want to move faster, but Dropbox's approach is a case study in managing risk. Lucas: Right. And the result is a sync engine that can handle one point two billion daily operations with a median latency under two hundred milliseconds.

That's the kind of number that makes you think about what's possible when you invest in foundational infrastructure. Luna: It also raises the question: how long until we see similar approaches in other consumer storage products? Google Drive, iCloud - they all face the same challenges. Lucas: They do.

And I think we'll see more of these block-level, content-addressable sync engines become the standard. Dropbox has essentially shown that it's feasible at planet-scale. The next frontier might be real-time collaborative editing at the block level, but that's a whole other conversation. Luna: For now, it's a great example of how investing in the core infrastructure - even if it takes years - can pay off in performance, reliability, and user trust.

Lucas: Exactly. And with that, I think we've covered the key architectural decisions. If you want to read the full technical deep-dive, Dropbox published their engineering blog series on it. Thanks for listening.