Hi guys,
wow, thank you so much for your quick replies even if it's sunday!!
It really looks like that one way to go is to move the responsibility of _id
generation for the booking to whatever other storage engine like redis so that
we maybe end-up with something like a _id microservice here.
_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
Hi Olaf,
> On 13. Dec 2020, at 11:13, Olaf Krueger 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
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
