Start With What CouchDB Printed
This is a real answer from a real database. CouchDB is a free database program that stores records as JSON text and can copy them between servers. I ran two CouchDB 3.5.1 servers on my laptop, did one small thing to them that I will show you in a minute, and then asked server A for one document. Here is exactly what came back, copied from my terminal:
GET /cards/bob?conflicts=true on A
{
"_id": "bob",
"_rev": "2-e052b9169c180799953262281bba5d9e",
"type": "card",
"name": "Bob",
"phone": "555-0199",
"email": "bob@old.example",
"edited_on": "A",
"edited_at": "10:00:05",
"_conflicts": [
"2-338f0aa2307732255657a41ac7920af2"
]
}
The first line is my question, not part of the answer. GET means "please read this for me", /cards/bob is the record I asked for, and ?conflicts=true asks the server to also list any competing versions of it. Everything inside the curly brackets is the answer. Let me read it with you, one line at a time, in plain words.
The document is a contact card for a person called Bob. A document in CouchDB is one record, written as JSON, which is a simple text format of names and values inside curly brackets. The first line, _id, is the name of the document: bob.
The second line, _rev, is the revision. Every time anyone changes a CouchDB document, the document gets a new revision string, like a version number with a fingerprint stuck on the end. This one starts with 2-, so it is the second version of the card.
Then come the fields I wrote myself: a phone number, an email address, and two labels, edited_on and edited_at, that my lab script puts into the card to remind us who made this version and what time it says on the label. CouchDB does not read those two labels. They are only there for us.
Now look at the last field, _conflicts. It holds one more revision string, also starting with 2-, but a different one. That is CouchDB telling me something important: there is a second version of this same card, made from the same starting point, and it is not the one being shown to me. That second version is the one where someone changed Bob's email to bob@new.example. You cannot see that new email anywhere above. The email shown is still the old one.
This is the full screen of the run I just quoted. Server B gives back the exact same winner and the exact same _conflicts list as server A, even though the two servers never asked each other who should win.
So the output is telling us three things at once. First, two different edits were made to one card. Second, CouchDB picked one of them to show, and both servers picked the same one. Third, the other edit was not thrown away. It was put to one side, and its name was written into _conflicts so that someone can deal with it.
The danger is in the third box. A program that reads this card without asking for conflicts would show the old email and never know a newer one exists. The data is safe, but it is hidden.
When two copies of the same data get changed in different ways and then meet, engineers call it a conflict. The work of deciding what the data should be after that is called conflict resolution. This whole lesson is about that work: what CouchDB does by itself, what it leaves for you, and how other databases answer the same question differently.