Inert Detritus The Internet's dust bunnies

CouchDB, and achieving consistency

What hap­pens when you change the same doc­u­ment in two dif­fer­ent data­bas­es and want to syn­chro­nize these with each oth­er? CouchDB’s repli­ca­tion sys­tem comes with auto­mat­ic con­flict detec­tion and res­o­lu­tion. When CouchDB detects that a doc­u­ment has been changed in both data­bas­es, it flags this doc­u­ment as being in con­flict, much like they would be in a reg­u­lar ver­sion con­trol system.

This isn’t as trou­ble­some as it might first sound. When two ver­sions of a doc­u­ments con­flict dur­ing repli­ca­tion, the win­ning ver­sion is saved as the most recent ver­sion in the document’s his­to­ry. Instead of throw­ing the los­ing ver­sion away, as you might expect, CouchDB saves this as a pre­vi­ous ver­sion in the document’s his­to­ry, so that you can access it if you need to. This hap­pens auto­mat­i­cal­ly and con­sis­tent­ly, so both data­bas­es will make exact­ly the same choice.

—CouchDB: Even­tu­al Con­sis­ten­cy. [empha­sis added]

Every appli­ca­tion that does sync­ing should sup­port some notion of “revi­sions”.

It takes only one sync algo­rithm mis­take or a bad con­flict res­o­lu­tion approach to suf­fer data loss. As more apps become “revi­sion-aware”, like Drop­box does so well, there’s many more nov­el things to be achieved with it, and this is one of them.

I very much agree that sync­ing and revi­sion his­to­ry should go hand-in-hand. It’s accept­ed that users make mis­takes and need undo. It’s pret­ty clear that in sync­ing, the com­put­er may make a mis­take that needs undo as well.