When You Can't Rely on CRDTs
If there are no concurrent operations, CRDTs and other solutions don't differ much (and lose their value). In handling parallel editing, CRDTs use predefined algorithms to ensure strong eventual consistency (i.e., if multiple people receive the same set of Ops, they will see consistent 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 merge results of parallel 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 parallel 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).