Centralized vs. Decentralized: Why Modern Collaborative Tools choose CRDTs

Real-time collaboration works like magic until two users edit the same line simultaneously. Under the hood, an algorithm must decide whose change wins and get it right every time.

Software engineers faced this problem and two major approaches emerged: Operational Transforms (OT) and Conflict-Free Replicated Data Types (CRDTs). The choice determines how your application scales.

OT requires a centralized system to have total ordering of operations to transform correctly. The core issue is when two servers receiving the same operations in different orders, produce different results. In addition, the number of transformation combinations grow exponentially as users grow, making edge cases and divergence common.

On the other hand, CRDTs are a decentralized data structure which was design to eliminate the need for a central coordinator. CRDTs achieve strong eventual consistency with its metadata, a unique identifier, relative position from peers and a timestamp.

Strong eventual consistency is achieved mathematically:

• Commutative - changing the order of operations does not change the result.


• Associative - receiving operations in different groups will not change the result.


• Idempotent - receiving the same operation twice will give the same result.

In the architecture of my Collaborative-Code-Editor, choosing CRDTs over OT gives me the advantage of not depending on a server for my data conflicts. Using Yjs as my CRDT library, not only fixes the problems OT arises but comes with additional features. A unique identifier keeps track of the characters' identity, and relative addressing that points to the character position in my code editor. The relative position matters because when working with other real-time data types that use indices, you will encounter stale data when inserting. In other words, when two users add character at the same time it will be inserted relative to the left and right parents rather than its place in the document.

Teams that build collaborative tools need to consider how to solve conflict data. CRDTs stand out as this algorithm that in addition to solving OT's scale issues, it lets developers not depend on a central server. In today's world where small teams and solo developer are emerging, they should consider using CRDTs if they need to scale without a central coordination server.