The real power of networking is unleashed when network-based distributed objects communicate with minimal conflict. A networked system providing a single service facet as a whole has a lot of distributed objects. Each object might share its state with other object or objects. These states might be orthogonal to each other or might be intrinsically intrusive. When they share the state, the updates can create some conflicts. Think of Google Docs as an example, where multiple authors can collaborate. Or think of it as an Amazon shopping cart that you and your loved ones share where one can add or delete some product simultaneously the other is adding or deleting a product. There is another example of Amazon, where a single cart is replicated across many servers. As the user adds or deletes products from the card, these update can land on different replicas of the same cart. How would one synchronize those updates? CRDT offer an elegant solution to such problems.

Most the above-mentioned scenarios are tackled in the realm of distributed computing. There is a multitude of algorithms available to provide synchronization among these distributed objects. One such very promising way to achieve order in updates is Conflict-free Replicated Data Types. There are two types of CRDTs, one is called Convergent CRDT (CvDRT) and the other is called Commutative CRDT (CmRDT).

Convergent CRDTs allow to converge or merge the data on each replica with any other replica. The data on each update on a specific replica is timestamped, so that the converge routines can make decisions based on these timestamps. Commutative CRDTs follow the commutative rule of mathematics. So this type only focuses on the operations rather than the data in each replica. Only these operation are delivered to each replica rather than the data. These operational updates are small messages so it is promising in terms of I/O as well.

There are many implementations of this datatype are now available e.g. in Java, AKKA, and Javascript. Their performance is getting better day by day.

There are other typical approaches to this problem as well. One such is Semantic Resolution. In the semantic resolution case, you take all the replicas and then perform checks on them in order to determine the fresh copy. In this approach, there is a lot of data overhead. Plus, semantic resolution takes into account the business interests of the business itself. Those might be different than serving the customer itself, e.g. maximizing the sales to hide e.g. the deletion conflicts among updates. So merging behaviour is not much of user-centric.

There are many types which are used in convergent only replication. One of them is Register. Register type allows you to do two operations on it. One is to set the register and the other is to get the value on the register. This register can be implemented using LWW (Last-Write-Wins) and Multi-Value. The CRDTs within the commutative approach are Counters, Sets, and Graphs. In counters we have Grow-only Counter, Positive-Negative Counter; in sets we have Grow-only set (only additions), 2P-set (Two-phase set which allows multiple additions and remove-once operations), and OR Set (Observed-Removed Set which allows multiple additions and removals); and graphs types use graph approach to add/remove updates (problematic so far).

If you want to learn more then you can see this tech report.