Member-only story
CouchDB: Document Conflicts

This article was originally published on priyathgregory.dev.
Three years ago, if someone asked me what couchDB was, I’d probably tell them it was some fancy piece of furniture. But that is three years ago, and since then, I have started a career, learnt a few things, and most importantly realized that couchDB has nothing to do with furniture.
CouchDB is in fact, a NOSQL database that plays an integral role in my current company’s tech stack. It has also been the source of many headaches over the years; And having messed around with it for the better part of three years, I have picked up a couple of things about couchDB that might help you avoid a few headaches of your own.
But first, lets first understand three key aspects of couchDB: The document and the revision tree, the changes feed, and the conflict resolution model.
The Document and the Revision Tree
Data in couchDB is represented as individual documents. A document is simply a JSON structure with a set of key value pairs, and a unique key for identification. Any update performed on a document will be tracked via a revision number.
A bare-bones couchDB document may look like this:
{
"_id": "my_document",
"_rev": "3-a",
"name": "Priyath Gregory"…