I'm under the impression that CRDTs are somewhat limited by the lack of a clear way to combine several structures along with application-specific logic.
In the 2012 paper "Logic and Lattices for Distributed Programming" (by Conway, Marczak, Alvaro, Hellerstein, and Maier) they write:
> CvRDTs present two main problems: (a) the programmer bears responsibility for ensuring lattice properties for their methods (commutativity, associativity, idempotence), and (b) CvRDTs only provide guarantees for individual values, not for application logic in general.
They give this example of the second point:
> A replicated, fault-tolerant courseware application assigns students into study teams. It uses two set CvRDTs: one for Students, another for Teams. The application reads a version of Students and inserts the derived element <Alice, Bob> into Teams. Concurrently, Bob is removed from Students by another application replica. The use of CvRDTs ensures that all replicas will eventually agree that Bob is absent from Students, but this is not enough: application-level state is inconsistent unless the derived values in Teams are updated consistently to reflect Bob's removal. This is outside the scope of CvRDT guarantees.
They continue:
> Taken together, the problems with [CvRDTs] present a scope dilemma: a small module (e.g. a set) makes lattice properties easy to inspect and test, but provides only simple semantic guarantees. Large CvRDTs (e.g., an eventually consistent shopping cart) provide higher-level application guarantees but require the programmer to ensure lattice properties hold for a complex module, resulting in software that is difficult to test, maintain, and trust.
This leads to a research project about monotonic logic as a distributed programming paradigm.
In the 2012 paper "Logic and Lattices for Distributed Programming" (by Conway, Marczak, Alvaro, Hellerstein, and Maier) they write:
> CvRDTs present two main problems: (a) the programmer bears responsibility for ensuring lattice properties for their methods (commutativity, associativity, idempotence), and (b) CvRDTs only provide guarantees for individual values, not for application logic in general.
They give this example of the second point:
> A replicated, fault-tolerant courseware application assigns students into study teams. It uses two set CvRDTs: one for Students, another for Teams. The application reads a version of Students and inserts the derived element <Alice, Bob> into Teams. Concurrently, Bob is removed from Students by another application replica. The use of CvRDTs ensures that all replicas will eventually agree that Bob is absent from Students, but this is not enough: application-level state is inconsistent unless the derived values in Teams are updated consistently to reflect Bob's removal. This is outside the scope of CvRDT guarantees.
They continue:
> Taken together, the problems with [CvRDTs] present a scope dilemma: a small module (e.g. a set) makes lattice properties easy to inspect and test, but provides only simple semantic guarantees. Large CvRDTs (e.g., an eventually consistent shopping cart) provide higher-level application guarantees but require the programmer to ensure lattice properties hold for a complex module, resulting in software that is difficult to test, maintain, and trust.
This leads to a research project about monotonic logic as a distributed programming paradigm.
http://bloom-lang.net
http://boom.cs.berkeley.edu