_id is indeed unique across the nodes of the cluster but that isn't helpful to your cause, because a document can have multiple, equally valid versions (called "revisions" in couchdb terms).
In CouchDB 2.x and 3.x, and with a default "N" value of three, each of the three nodes will accept a write independently of the others. There is an anti-entropy system that ensures, in the absence of error, all writes at any one of those nodes will reach all of the others, introducing a "conflict" revision if necessary. What this means is if you had two writers trying to create "slot1:booked", they might each succeed in updating at least one of the three nodes. Once both writes have reached all three nodes, any subsequent read will see only of of those writes (the so-called "winner"). The other write is retrievable with extra options (?conflicts=true and others). So, you could not build a mutual-exclusion lock or auto-incrementing counter using a single document. We are building a new version of CouchDB, which will be designated 4.0 when it's finished, which fundamentally shifts from an availability focus to a consistency focus (AP -> CP). In that version you could attempt concurrent updates to the same document and be sure that only one write will succeed and the others definitively and permanently fail. B. > On 13 Dec 2020, at 10:26, Jan Lehnardt <[email protected]> wrote: > > Hi Olaf, > >> On 13. Dec 2020, at 11:13, Olaf Krueger <[email protected]> wrote: >> >> Hi again, >> >> we're working on a booking app. >> In order to prevent over booking of a particular slot (A slot can booked >> only once), it's crucial to know if a slot is already booked or even not. >> >> We're using a cluster of 3 CouchDB nodes, so having the eventual consistency >> issue in mind the question is, if it's possible to basically achieve the >> above requirement. >> >> The idea is to create an own document for each booking by using a custom >> _id, e.g. >> { >> _id: = "slot1:booked >> } >> >> But that would probably only work if CouchDB guarantees the uniqness across >> all nodes. >> Is that the case? >> Or do we have to accept that consistency is sacrificed in favour of >> availability? > > Yes. > >> Or do we need to think about using another DB which sacrifies availability >> in favor of consistency? > > Unless you can resolve a double-booking after the fact, yes. A memcached or > redis instance is often used in conjunction with CouchDB, but other > unique-id-register mechanisms exists. > > Best > Jan > — >> >> Many thanks! >> Olaf >> >> >
