Basically, your storage has container types ("T"). A list, a set, a dictionary, etc. Container types can be split and added together in a distributed fashion ("R" and "D").
The "C" in CRDT stands for "Convergent and Commutative" to imply your distributed operations can obtain the same value when merged.
Quick example: If you have a node with a key pointing to value (set) [a, b, c] and another node with the same key but different value [c, e, f], then when the nodes communicate, they can do a set union for the actual result of [a, b, c, e, f]. Keys can keep a running log of recent operations to clean up the global result too (like: [c, e, (recently deleted f)], so on merge, if the other list has f, it would be deleted instead of re-added).
Before CRDTs were a thing, Bob made state box and it's very easy to understand. Give the README a read to understand more basics: https://github.com/mochi/statebox
At the surface they sound like something vaguely resembling an abelian group (+/- inverses), but the conflict resolution stuff is the heart of it I'd guess.
If this floats your boat, here's me on CRDTs: https://skillsmatter.com/skillscasts/5301-convergent-replica...
CRDTs wont have mainstream success until people stop using the words 'monoid' and 'abelian' etc.
Most programmers aren't required to learn this kind of math in a CS degree, AND furthermore, many programmers dont have a CS degree/forgot it.
So the question is, are CRDTs a useful technique for all developers, or just a way for a minute few to demonstrate their ability to sling around math words?
In another context I would have avoided those terms and perhaps used an explanation like this: http://noelwelsh.com/programming/2013/12/20/crdts-for-fun-an...
http://research.microsoft.com/apps/video/default.aspx?id=153...