But putting raw scale aside, file synchronization is a unique distributed systems problem, because clients are allowed to go offline for long periods of time and reconcile their changes when they return.

The scale of Dropbox alone is a hard systems engineering challenge. Our first sync engine, which we call ”Sync Engine Classic,” had fundamental issues with its data model that only showed up at scale, and these issues made incremental improvements impossible. Syncing files becomes much harder at scale, and understanding why is important for understanding why we decided to rewrite. Dropbox servers store files durably and securely, and these files are accessible anywhere with an Internet connection.

The user installs the Dropbox app, which creates a magic folder on their computer, and putting files in that folder syncs them to Dropbox servers and their other devices. At first glance, a lot of Dropbox sync looks the same as today. To begin, let's rewind the clock to 2008, the year Dropbox sync first entered beta. In particular, we’re going to share reflections on how to think about a major software rewrite and highlight the key initiatives that made this project a success, like having a very clean data model. It turned out that this was an excellent idea for Dropbox but only because we were very thoughtful about how we went about this process. Rewriting the sync engine was really hard, and we don’t want to blindly celebrate it, because in many environments it would have been a terrible idea. We're proud to announce today that we've shipped this new sync engine (codenamed 'Nucleus') to all Dropbox users. The sync engine is the magic behind the Dropbox folder on your desktop computer, and it's one of the oldest and most important pieces of code at Dropbox. Over the past four years, we've been working hard on rebuilding our desktop client's sync engine from scratch.

Dropbox app not syncing