## 6 System Development
### Crdt
#### 6.3.2 Server-Side Conflict Resolution  
In this case, the server will be the authority (also called the leader) to decide how the conflicts are resolved, thus the server-side application running the code that handles the document changes needs to be stateful. This is a major issue for a dependable system since it requires a way to handle the application state in case of a system disaster. It also makes the server side a key component for the minimum functionality of the system.  
All the clients need to talk directly to the specific server that holds the state of the document, creating a problem in terms of scalability and cloud agnosticism (Figure 15).  
Figure 14: Executing a transaction between clients.  
The server application needs to have an in-memory state and custom application logic that needs to be continuously saved and restored in the case of a disaster. The operation consumption and server-side processing may affect the availability of the system in big collaboration groups where multiple changes could be applied in a short time. Since the server obtains from the client only the operations that the user generates, it must deal with and adapt the operations to converge the state of each user.  
For example, when a user deletes from a position where previously a character was inserted, the deletion index needs to be updated to delete the initial designated value.  
\(S\) = \"_Test\"_  
_Client A: INSERT('A', 1) \(\rightarrow\) \"TAest\"_  
_Client B: DELETE(1) \(\rightarrow\) \"Tst\"_  
In this example, the second client intended to delete the character \"e\" but due to the previous insertion of the first client, it will delete the character \"A\". To achieve convergence, the delete operation emitted by the second client needs to be updated to delete the initial character on the indicated position (\"e\"). In other words, the delete operation needs to be applied on index 2. To converge to a final state, each client's operations must be broadcast to all the other clients.  
\(S\) = \"_Test\"_  
_Client A: INSERT('A', 1) && DELETE(2) \(\rightarrow\) \"TAst\"_  
_Client B: DELETE(2) && INSERT('A', 1) \(\rightarrow\) \"TAst\"_  
Based on this example, a key aspect of this operations handling can be extracted: each applied operation must be commutative to obtain convergence. This methodology of handling and altering incoming operations applied to a resource is called Operational Transformation (OT). OT was created in 1989 and was designed to offer a way of handling concurrent resource editing in a non-blocking way without utilizing data locks [59]. It is a technique used in collaborative editing systems to ensure consistency and convergence of shared documents. The algorithms require dedicated stateful management of the resource that is edited making the server side, not only a communication layer but also a coupling part of the overall architecture [60; 61].  
For the proposed architecture, to achieve scalability, the microservices should ideally be only an agnostic communication layer and a way to interact with the database persistence layer. Thus, in case of a service failure, it can spawn back and resume work without the need for data recovery and a dedicated mechanism for periodic backups.  
The conflict resolution step can be moved to the client side and the server can become only a communication channel and can independently produce side effects such as saving the document state based on a strategy and collecting execution logs. To implement this approach a special datatype is required: CRDT.  
Figure 15: Multi-client consumers on a single server.