undefined | Better HN

0 pointsOskarS2y ago0 comments

I've always wondered if it's a good trick for horizontal scaling as well. Like, if you have one server serving 1,000,000 clients, using a CRDT you could trivially split that up into 10 servers serving 100,000 clients each, and then have the ten servers be peers to each other.

0 comments

josephg2y ago

The one “downside” compared to regular databases is that CRDTs use optimistic concurrency. If you want transaction support, or want multiple writers to block each other, CRDTs are a bad fit. They move conflict resolution to the point when reads happen rather than make writers fetch and retry.

Still fine for a lot of use cases though.

fauigerzigerk2y ago

>The one “downside” compared to regular databases is that CRDTs use optimistic concurrency.

My understanding of the term "optimistic concurrency" is that a write operation can fail if the optimism turns out to be misplaced (so to speak). CRDTs on the other hand always merge deterministically and never fail, even if application level consistency constraints are violated.

This is why CRDTs are rarely useful to me, but I can see how they may be useful in domains that can live with the very weak form of consistency guarantees that CRDTs can provide.

filleokus2y ago

> even if application level consistency constraints are violated.

I think, in theory at least, it should be possible to encode the application level constrains into the CRDT merging algorithm. Like how two edits making different (but overlapping) spans bold are fine to merge into one bold span, but i.e highlighting with different colors are not.

Of course the merge will never be "perfect", as it is impossible to encode all human wishes into the CRDT, but I think there is a lot of room to improve when it comes to merging non-text data.

fauigerzigerk2y ago

I don't think it is theoretically possible, but even if it was, it would be tantamount to inventing one or more new CRDTs per application. Each begin/end transaction block would become its own research project.

j / k navigate · click thread line to collapse

0 comments

josephg2y ago

Still fine for a lot of use cases though.

fauigerzigerk2y ago

>The one “downside” compared to regular databases is that CRDTs use optimistic concurrency.

This is why CRDTs are rarely useful to me, but I can see how they may be useful in domains that can live with the very weak form of consistency guarantees that CRDTs can provide.

filleokus2y ago

> even if application level consistency constraints are violated.

Of course the merge will never be "perfect", as it is impossible to encode all human wishes into the CRDT, but I think there is a lot of room to improve when it comes to merging non-text data.

fauigerzigerk2y ago

j / k navigate · click thread line to collapse