Collaborative text editing is an easy-to-understand example of a Hard Problem that can't be solved with any simpler abstraction. You can try to throw an MVCC da

Collaborative text editing is an easy-to-understand example of a Hard Problem that can't be solved with any simpler abstraction. You can try to throw an MVCC database at it, a BFT consensus algorithm at it, whatever, but without having those substrates implement a CRDT (or its cousin, Operational Transformations), you won't get the results you want. More generally, CRDTs are useful when syncing any kind of change-events between peers (with no central ability to pre-linearize those events), where the ordering of change-events doesn't matter — i.e. where the operations described by the events are "commutative", such that you'll get the same results out if you apply events {1,2,3} or {3,2,1} or any other order. As long as all peers see all events, all peers arrive at the same eventually-consistent position in the "lattice" of possible states. In other words, CRDTs + gossip protocols = the ability for peers to just process events as they hear about them, without a worry about receiving events from peers "out of order"; rather than needing to wait around for a some elected peer to forcibly linearize the events (i.e. without the need to introduce a serial write bottleneck.) A good example of the distributed-systems-backend kind of use of CRDTs, is in the Elixir web framework Phoenix, which does a sort of mesh delivery of web-socket messages between a cluster of backends. CRDTs are used to sync presence information (= which clients are connected to which backend) between the backends.