Strong Eventual Consistency – the Big Idea Behind Crdts

Posted4 months agoActive4 months ago

todsacerdoti

35 points

12 comments

lewiscampbell.techTechstory

calmpositive

Debate

40/100

CrdtsDistributed SystemsDecentralization

Key topics

Crdts

Distributed Systems

Decentralization

The article discusses Conflict-free Replicated Data Types (CRDTs) and their reliance on Strong Eventual Consistency, sparking a discussion on decentralization, data ownership, and the potential for peer-to-peer systems.

Snapshot generated from the HN discussion

Discussion Activity

Moderate engagement

First comment

Peak period

72-84h

Avg / period

Comment distribution12 data points

Loading chart...

Based on 12 loaded comments

Key moments

01Story posted
Sep 8, 2025 at 6:42 AM EDT
4 months ago
Step 01
02First comment
Sep 11, 2025 at 12:03 PM EDT
3d after posting
Step 02
03Peak activity
9 comments in 72-84h
Hottest window of the conversation
Step 03
04Latest activity
Sep 12, 2025 at 4:58 PM EDT
4 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (12 comments)

Showing 12 comments

an0malous

4 months ago

1 reply

We need a true peer-to-peer Internet instead of the centralized, feudal system we currently have. CRDTs would allow for peers to own their data and collaborate without centralized servers owned by Big Tech, but even the network itself goes through a small number of pipes owned by telecom companies that can decide what gets through and when. Decentralization is the real big idea behind CRDTs.

gobdovan

4 months ago

1 reply

That's like saying hash tables will fix cloud computing monopolies. They're really neat for collaborative tools at application level, but it doesn't solve any of the infrastructure problems.

They're not even the missing piece in decentralized infra either. There are alternatives that work as efficiently.

an0malous

4 months ago

> That's like saying hash tables will fix cloud computing monopolies.

No it’s not because there’s nothing about hash tables that enables peer to peer collaboration over centralization. CRDTs do because you don’t need a “master” or “central” source of truth anymore.

> They're not even the missing piece in decentralized infra either.

Then what is?

I didn’t say they were anyway though, that’s why I mentioned network infrastructure as another constraint.

Jtsummers

4 months ago

1 reply

This one isn't a dupe, it came back through the second chance pool but in the meantime a second submission did take and got a lot of comments:

https://news.ycombinator.com/item?id=45177518 - 87 comments

trosenbaum

4 months ago

This sequence of events ended up very relevant, given the subject matter. :D

cryptonector

4 months ago

2 replies

What is the monoid for table primary keys?

BoiledCabbage

4 months ago

1 reply

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".

cryptonector

4 months ago

No, because primary keys are things like names, not random numbers.

giovannibonetti

4 months ago

Vector clocks, since they keep a separate counter for each client

lamp_book

4 months ago

1 reply

We really ought to come up with some new terms in this space... it is just confusing to mix "strong consistency" in with "eventual consistency" in any way.

toomim

4 months ago

Why is that confusing?

This "Strong Eventual Considtency" is the defining property of the CRDT. Do you have a less-confusing way to think about that property?

pradn

4 months ago

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.)

View full discussion on Hacker News

ID: 45166698Type: storyLast synced: 11/20/2025, 4:56:36 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN