5 ms·

> Don’t fret if you’re a fan of central authority though, Figma successfully uses CRDTs server-side to handle the collaborative aspects of their product, as wel

> Don’t fret if you’re a fan of central authority though, Figma successfully uses CRDTs server-side to handle the collaborative aspects of their product, as well as Soundcloud and many others. Why bother with CRDTs if you’re doing server-side synchronization? MMORPGs can handle synchronizing thousands of users without problem.

hnb2137 3y ago
CRDTs solve the problem of concurrent updates bij users.
- tomaskafka 3y ago
  And offline edits from concurrent users
  - OskarS 3y ago
    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.
    - josephg 3y 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.
      - fauigerzigerk 3y 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.
        filleokus 3y 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.
        fauigerzigerk 3y 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.

hnb2137 3y ago

CRDTs solve the problem of concurrent updates bij users.

tomaskafka 3y ago
And offline edits from concurrent users
- OskarS 3y ago
  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.
  - josephg 3y 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.
    - fauigerzigerk 3y 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.
      - filleokus 3y 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.
        fauigerzigerk 3y 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.