Live data from Hacker News

Strong Eventual Consistency – The Big Idea Behind CRDTs

lewiscampbell.tech

11–14 of 14 posts

Re: Strong Eventual Consistency – The Big Idea Behind CRDTs

#11
A common pattern I see is data-plane nodes receiving versioned metadata updates from the control-plane. As long as the version is higher than the node's previous one, it's correct to use. So, the metadata is a sort of monotonic counter with a bag of data attached to it. This pattern produces a monotonic counter, which I assume is a naive sort of CRDT - though the data itself doesn't benefit from CRDT merge semantics. In this world, as long as a node gets an update, its going to incorporate it into its state. In the article's terms, the system has Strong Convergence.

I'm trying to figure out under what practical circumstances updates would result in Eventual Convergence, not Strong Convergence. Wouldn't a node incorporate an update as soon as you receive it? What's causes the "eventual" behavior even after a node gets an update?

It seems to me the trouble is actually getting the update, not the data model as such. Yes, I realize partial orders are possible, making it impossible to merge certain sequences of updates for certain models. CRDTs solve that, as they're designed to do. (Though I hear that, for some CRDTs, merges might result in bad "human" results even if the merge operation follows all the CRDT rules.)

Re: Strong Eventual Consistency – The Big Idea Behind CRDTs

#12

What is the monoid for table primary keys?

Im guessing generating unique ids instead of incremental numbers?

Maybe not as long as uuids, but long enough to be comfortable they won't conflict withing your table/db.

Those will merge fine as two separate "rows".

Re: Strong Eventual Consistency – The Big Idea Behind CRDTs

#13

What is the monoid for table primary keys?

Im guessing generating unique ids instead of incremental numbers? Maybe not as long as uuids, but long enough to be comfortable they won't conflict withing your table/db. Those will merge fine as two separate "rows".

No, because primary keys are things like names, not random numbers.
Post reply on HN