How Dropbox Resolves Conflicts, Or Not

Guido van Rossum, now at Dropbox, is starting a series of posts that describe how the Dropbox data store syncs arbitrary tables of data across clients. Of note to me is how they resolve conflicts. In short, they don’t:

If you’re familiar with the theory of Operational Transformation (OT), you might be surprised that the server doesn’t even attempt to resolve conflicts. We use OT-style conflict resolution on the client, but leave the server to simply serialize requests. This allows conflict resolution to be defined by the client — your app — giving you more freedom than traditional approaches (which usually require that the rules for conflict resolution be fixed). As you will see next time, a Datastore API client may customize conflict resolution to fit its own requirements.

Quite reminiscent of git. You try to apply your batch of changes. If Dropbox says you are not up to date with other changes, it’s your job to replay your set of changes on top of the current state of truth. Then you try to apply your freshly rebased batch of changes back to the server again.

General purpose syncing is hard, hard, work. This series will be useful not just because it shows off Dropbox’s forethought, but because it shows how much engineering is necessary to solve the really useful problems we have today.