Extensible Conflict-Free Replicated Datatypes for Real-time Collaborative Software Engineering

Real-time collaboration has become a prominent feature of nowadays’ software engineering practices. Conflict-free replicated data types (CRDT) offer efficient mechanisms for implementing real-time collaborative environments. However, the lack of extensibility of CRDT limits their applicability. This is a particularly important problem in settings relying on complex, non-linear data types. In this paper, we report our results in augmenting primitive CRDT with extension mechanisms. We demonstrate our technique through an example from the realm of model-driven engineering, where graph types are prevalent.


I. INTRODUCTION
T ODAY'S software engineering is often carried out in distributed settings [1], necessitating advanced coordination mechanisms, such as real-time collaboration. A key challenge in real-time collaboration is to guarantee the convergence of the stakeholders' local replicas while ensuring timely execution and smooth user experience [2]. Traditional mechanisms that implement locking [3] fall short of addressing this challenge. A more appropriate consistency model for realtime collaboration is strong eventual consistency (SEC) [4]. SEC ensures that (i) the updates will eventually be observed by each stakeholder, and (ii) the local replicas that received the same updates will be in the same state.
Conflict-free replicated Data Types (CRDT) [5] provide an efficient implementation of the SEC model. While CRDT have been successful in supporting real-time collaboration over linear data types, such as text and source code, some applications require more complex data types. For example, graph models are frequently employed in Model-Driven Software Engineering (MDSE) [6]. However, the lack of appropriate extension mechanisms in current CRDT frameworks renders the definition of more complex data types a challenging task.
In this paper, we report on our experiments with extensible CRDT using our prototype framework, CollabServer 1 . The contributions include (i) a collection of CRDT primitives; (ii) an extension mechanism for the customization of CRDT; and (iii) performance assessment of the approach. We demonstrate our approach on an illustrative case for Mind map editors, which represents typical modeling environments that require graph semantics to represent models.

II. BACKGROUND
Collaborative Model-Driven Software Engineering: The challenges of distributed software engineering are substantially exacerbated by the complexity of the engineered system that necessitates collaboration between stakeholders of highly diverse expertise. Model-driven software engineering (MDSE) [6] allows stakeholders to reason at higher levels of abstraction and by that, enables aligning the work of diverse stakeholders. Combining the benefits of collaborative software engineering with MDSE, collaborative MDSE [7] has become a prominent paradigm in software engineering practice. Due to the often disparate vocabularies of stakeholders, identifying overlaps between the stakeholders' concerns is not trivial [8]. This, in turn, renders the detection of conflicts a challenging task. Recent studies [9], [10] show that only one-third of realtime collaborative MDSE solutions provide explicit conflict resolution mechanisms. State-of-the-art tools mostly rely on version control systems to facilitate collaborative MDSE [11]. Other approaches define consistency in terms of bijective correspondence, e.g., by linking elements through correspondence graphs [12], processes [13], or semantic links [14]. However, these techniques do not support real-time collaboration.
Real-time collaboration and CRDT: Sun et al. [2] define four requirements for effective real-time collaboration: (i) convergence of replicas; (ii) user intention preservation; (iii) causality preservation of updates; and (iv) timely execution of updates. CRDT support real-time collaboration by eliminating conflicts between the distributed stakeholders' operations, without the need for a costly consensus mechanism, while showcasing excellent fault tolerance and reliability properties. Notable open-source CRDT frameworks include Automerge 2 and Yjs 3 . Automerge enables real-time collaboration in JavaScript-based systems, based on the JSON format. Yjs uses linked lists as its foundational data type, but the internal representation can be extended to achieve collaboration over complex data types. However, this extension is not trivial.

III. THE COLLABSERVER FRAMEWORK
A. Design principles 1) Operation-based CRDT: There are two equivalent approaches to implementing CRDT. State-based CRDT are structured in a way that they adhere to a monotonic semilattice. Operation-based CRDT require that concurrent operations commute, i.e., irrespective of the order of operations, local replicas converge. We have opted for the operationbased CRDT scheme. This approach, as opposed to statebased CRDT, requires less network bandwidth, because only operations have to be sent through the network. In addition, an operation-based approach is more suitable for integration with external components, such as databases and user interfaces.

2) Last-Writer-Wins (LWW):
Automated reconciliation between replicas can be achieved at the application level or at the data level [15]. The LWW paradigm [16] implements the latter and has been widely adopted for operation-based conflict resolution. In LWW, conflicted operations are resolved by timestamps; the data with the more recent timestamp prevails. Fig. 1 shows an example resolution scenario under LWW. User A and User B initially have their local replicas in consistent states. At t = 1, User A executes the update x = 15. The updated value and the timestamp are propagated to User B. However, before the message arrives, User A executes another update: x = 20, at time t = 2. The update is propagated to User B. Networks usually do not guarantee order preservation. Thus, the second update may arrive at User B earlier than the first. Upon receiving the update, User B will reconcile this new value with his local replica. User B has x = 10 timestamped with t = 0; and an update that says x = 20 timestamped with t = 2. Under the LWW paradigm, the latter value is accepted. Eventually, the first update reaches User B. User B has x = 20 timestamped with t = 2; and an update of x = 15 timestamped with t = 1. Under the LWW paradigm, the former value is accepted, leaving the replicas in consistent states.
3) CRDT tombstone metadata: To ensure that operations commute, data is never deleted, only flagged as removed (i.e., soft delete). This information is captured in the tombstone metadata with boolean semantics. In an alternative approach by Shapiro et al. [5], dedicated partitions of the specific datatypes are reserved for storing deleted elements (LWWelement-Set). The benefit of our approach is that it reduces the number of elementary data operations upon changes.

4) Commutativity and idempotence:
Operation-based CRDT assume that operations commute (i.e., x ç y = y ç x) and are idempotent (i.e., x ç x = x). Traditionally, these properties are ensured by the communication protocol [5]. We have implemented the base type system of CollabServer in a way that commutativity and idempotence are guaranteed by design. As a consequence, CRDT that extend base CollabServer types are expected to satisfy these properties without further development effort. Commutativity and idempotence are achieved by the combination of timestamps and tombstones. Timestamps ensure that each replica will order the update operations in the same way. Tombstone metadata ensures that no information is lost. Table I summarizes the CRDT provided by CollabServer. Every CRDT is equipped with atomic create, read, update, and delete (CRUD) operations. More complex operations can be implemented in specific applications. CollabServer is implemented in C++, using the Standard Template Library (STL) [17]. At the source code level, CollabServer CRDT are implemented as C++ templates, allowing easy extensibility and customization. More information is available in [18] and from the GitHub repository of the project 1 . In the following, we briefly discuss the CRDT provided by CollabServer.

1) LWWRegister:
The LWWRegister is the simplest primitive implemented in the CollabServer framework. It stores an atomic value, its timestamp ts, and its tombstone metadata. The query method returns the value stored in the register. The update method changes this value, as shown in Algorithm 1.
2) LWWSet: The LWWSet is a monotonically increasing data structure with the usual set semantics. That is, a value can exist in the set only once. The LWWSet is implemented as a C++ HashMap, with the values stored in the key set, and the associated value set storing the metadata (timestamp and tombstone). The query method (Algorithm 2) returns the respective key of the hashmap if it exists and is not marked as removed. The add method (Algorithm 3) inserts an element into the set. If the element already exists in the set, its timestamp is updated. If the element does not exist in the set, it is added to the set, along with the required metadata. The remove method (Algorithm 4) flags an element as deleted if its timestamp is higher than the current timestamp. In case the element is already deleted, its timestamp is updated, and a false value is returned. If the requested element is not present in the set, it is added with tombstone metadata that designates a deleted state. The clear method executes the remove method on every element in the set.

3) LWWMap:
The LWWMap stores key-value pairs of data with the keys being stored in an LWWSet and the associated value being stored in an LWWRegister. By reusing the previously defined LWW types, the API methods of the LWWMap can be reduced to the ones defined in Algorithms 1-4.

IV. CUSTOMIZING CRDT
In this section, we demonstrate the extensibility of Collab-Server CRDT by (i) constructing a custom physical CRDT, the LWWGraph (Section IV-A); and (ii) based on this custom type, constructing a domain-specific type (Section IV-B). For the latter, we use the example of a Mind map editor, providing domain-specific operations for constructing and manipulating a Mind map, such as adding and removing topics; and placing a marker on a topic. Fig. 2 show the extended type system.

A. Constructing custom CRDT: LWWGraph
The LWWGraph is a directed graph, represented by its adjacency list, stored in an LWWMap. Vertex IDs are stored as keys and the vertices are stored as values. There are no restrictions on the type of the vertex ID, it only depends on the specific implementation, and its typing is deferred to the developer. A vertex is defined as a tuple (content, edges), describing the content of the vertex and an LWWSet of the outgoing edges from this vertex. Each key is the ID of the target vertex. The queryVertex method invokes the query method on the LWWMap storing the adjacency list of vertices, and returns the vertex if exists. Similarly, the addVertex method invokes the add method on the LWWMap storing the adjacency list. The removeVertex method (Algorithm 5) removes a vertex from the graph, and all edges connected to it. If the vertex does not exist yet, it is added in the adjacency list, and the remove method of the LWWMap is invoked. The addEdge method (Algorithm 6) creates a new edge connecting the source vertex with the target vertex. We distinguish between three scenarios. First, we apply addEdge on two existing vertices. In this case, the edge is added to the underlying graph; or if the edge already exists, its timestamp is updated. Second, we apply addEdge when one or two vertices do not exist. This case occurs when the addEdge operation is observed before the addVertex operation. To ensure the commutativity of operations, CollabServer implements the addEdge method in a way that it also applies addVertex on the source and target vertices. Missing vertices are then simply added along with the edge. Receiving a later addVertex operation will simply update the timestamps. Third, we apply addEdge with the source and/or the target vertex that has already been deleted. This case occurs when the addEdge operation is received with the source and/or the target vertex already deleted. The case where removeVertex is older than addEdge is a trivial one, since addEdge also applies addVertex as seen earlier. The opposite case (removeVertex older than addEdge) requires additional steps. First, the edge is created as discussed before. Then, we check if the newly created edge is dangling and remove it. This way, addEdge is commutative. Note that, as shown in Algorithm 6, this operation returns more information since additional actions can be performed on the edge or the vertices. The removeEdge method (Algorithm 7) removes an edge from the graph. This operation may encounter a situation where the source vertex does not exist yet in the graph. Since all operations are required to be commutative, the source vertex is created with the smallest timestamp and the isRemoved flag is set to true. The clearVertices method removes all vertices and their associated edges from the graph.

B. Constructing domain-specific CRDT
The construction of custom CRDT is achieved by extending the CollabData base type and defining custom operations while ensuring their commutative and idempotent properties. We demonstrate the extensibility of primitive CollabServer data types by constructing the MindMap CRDT for the MindmapEditor application. The MindMap type is a graph; each topic and marker of the MindMap is a vertex of the graph; edges of the graph connect topics to their parent topic, and markers to the topics they mark. Constructing the MindMap requires extending the LWWGraph primitive type and augmenting it with domain-specific methods that are commutative and idempotent. The outline of the MindMap CRDT is shown in Listing 1. The full implementation is available from the GitHub repository of the project. 1 The methods in Listing 1 reuse the API of the LWWGraph; thus, they inherit CRDT properties. The MindMap type extends the LWWGraph by introducing the notion of attributes, for example, for storing the name of the MindMap. As shown

V. PERFORMANCE EVALUATION
Although performance was not our primary concern in this exploratory project, we provide a performance evaluation of the framework. As the performance of CRDT is determined by the number of objects present in the application [19], we assess the performance by simulating a scenario in which new vertices and edges are added to a shared model.
Experimental setup: We used the following sequence as a test scenario: add topic i → add topic j → connectTopics topic i , topic j The scenario was executed 50.000 times. That is, 100.000 topics (graph vertices) and 50.000 relationships (edges) were generated. We have executed the test scenario with one, two, and four parallel users, and measured the change in response times. In the case of two and four parallel simulated users, each user carried out Results: To assess the scalability of the framework, response times were measured at the local replicas, defined as the time difference between issuing a command in the editor and getting a response. To filter noise, we clipped the sample at µ ± 3σ (0.2% of the cases). The mean response time in the one-user case shows linear scaling with the number of objects. (Linear regression statistic: p = 22E 2 17.) We have observed the same linear increase in response times in the two and four-user cases. We have also observed increasing response times with the increasing number of users. Table II shows the mean response time in one, two, and four user cases. The mean response time increased by a factor of 2.2 and 2.8 as the number of users doubled from one to two, and from two to four, respectively. A statistically significant difference is observed in the mean response time of the three cases, as confirmed by a t-test (α = 0.05, p =2e-11).
We observed a linear increase in the memory heap. The majority of memory consumption is due to C++ node iterators and hashtable objects the LWWGraph relies on.
Discussion: We observe a linearly increasing response time and a linearly increasing memory footprint. This is in line with the observation of Sun et al. [20]. We conclude that this performance profile is characteristic of CRDT implementations, and can be effectively treated by suitable garbage collection mechanisms [21]. We consider these results adequate (i) considering the benefits in extensibility CollabServer CRDT provide; and (ii) considering that performance was not the primary objective of the current solution.

VI. CONCLUSION
In this paper, we presented an approach for augmenting CRDT with extension mechanisms and demonstrated that the performance repercussions of extensibility are manageable. We provided a family of concurrency control algorithms, ensuring strong eventual consistency and allowing for efficient real-time collaboration. Our algorithms and data types show linear scaling of response time and memory footprint with the number of objects in memory and with users. This is a characteristic performance profile of CRDT. Our results suggest that CRDT can be used in disciplines where customizability is a key factor, such as collaborative modeling using domain-specific modeling languages. In future work, we will investigate garbage collection mechanisms to achieve the scalability collaborative engineering tools require. We used the takeaways of this exploratory project in the development of our real-time collaborative modeling framework lowkey [22].