When Not to Rely on CRDTs

If there are no concurrent operations, CRDTs and other solutions don't differ much. In handling concurrent editing, CRDTs use predefined algorithms to ensure strong eventual consistency (i.e., if multiple people receive the same set of Ops, they will see the same content). Furthermore, some CRDT algorithms make the merge results as close to user expectations as possible.

However, its problems include:

• Difficulty in maintaining user-defined invariants. For instance, in a meeting room reservation scenario, a room can only be booked once. But if CRDTs represent the reservation status, multiple people booking the same room simultaneously may all see a successful operation, but in reality, only one person will have the reservation after synchronization. Thus, other systems are needed to maintain these invariants.
• Automatic merged results of concurrent edits may violate the schema. For example, automatically merged code edits may not comply with the code's syntax structure, requiring human intervention to adjust. The requirement that a <figure> can only contain one <caption> might also be violated in concurrent editing (two people inserting a new <caption> concurrently). For such scenarios, this issue can be ignored, or <caption> can be represented differently (changing <caption> from a List element to a Register on a separate Map can prevent this problem).