Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CRDTs: Convergence without coordination

read.thecoder.cafe

Post reply on HN
Print view View original

31–34 of 34 posts

Re: CRDTs: Convergence without coordination

#31

Post by gregoriol »

ffsm8 wrote: post #24
gregoriol wrote: post #9

Earlier quoted context omitted.

CRDTs mostly have a time notions like Lamport clocks, vector clocks, ... not actual device time => see more here: https://adamwulf.me/2021/05/distributed-clocks-and-crdts/

All of which have their own weaknesses. And all of them can suffer the split brain scenario. And all but the last one fundamentally have lots of edge cases with e.g. high-latency sync

CRDTs are not a solved problem as of today, there is no perfect solution in the current state-of-the-art, it's still a field with quite some active research.

Re: CRDTs: Convergence without coordination

#32

Post by apex_sloth »

Arcuru wrote: post #19

Shameless plug: I'm betting that a lot of applications could use some form of CRDT as a Database, which would allow a fully decentralized backend/database for local-first apps. So I've been building one. Still working on good blog posts to explain and introduce it though. https://github.com/arcuru/eidetica

That looks awesome! Do you have any metrics on storage space and query/insert performance for large amounts of data? Building something that has couple of million rows.

Re: CRDTs: Convergence without coordination

#33

Post by jongjong »

edbaskerville wrote: post #25
jongjong wrote: post #11

Earlier quoted context omitted.

Yes, it's impossible for a distributed system to figure out the collaborative intent when it sees conflicting changes... Even the people who made the changes may not 'know' what is the correct way to resolve the conflict... For that to happen, people involved would have to communicate and agree on either option or they would have to agree on a compromise. This problem cannot be solved automatically because computers…

I think the really interesting problem in this space is designing UIs and data structures that, on the one hand, capture as much user intent as possible, but, more importantly, make it easier for users to manage conflicts. I.e., if there's a tricky conflict, the app need not resolve it at all. Rather, it should provide, by default, a nice way for the user to manage the resolution as part of the normal workflow. Or, p…

For CRUD applications with real-time updates, I find that updating individual fields as opposed to overwriting the entire record works sufficiently well. It can be dome relatively cheaply using WebSockets. Would be overkill to use HTTP to update individual fields (as each request carries redundant headers) but WebSocket frames are very lightweight. I've built a serverless platform on this principle and it helps to simplify the frontend components.
Post reply on HN