- At t = T6 , Alice re-sends M1
What Bob sees is consistent with what the server sees at T6 but there’s a divergence (inconsistency) between Alice’s chat history and Bob’s chat history. This is because when Alice comes back online at T3 , Alice’s client does not download a fresh copy of the chat history from the server.
We avoid the need to solve the conflict resolution problem by keeping the client version after the network connection is established again and not forcing it to be consistent with the server version. As there’s no polling, the only server-driven update to the client replica is from WebSocket events.
The OkCupid chat app lets you go offline for an arbitrary amount of time and continue sending new messages. However, when you are online again, it doesn’t automatically download all the messages sent to you when you were offline and re-apply your offline edits on top of the latest state.
Choosing an appropriate final state when concurrent updates have occurred is called reconciliation and can be quite tricky to implement.
For instance, there’s a downside to simply syncing the replicas with the server state when the system reaches steady-state: It can violate the invariant for our collection wherein messages are always ordered by the time they were created. This has some usability implications as it can create a jarring user experience to see the messages in the chat history suddenly change order.
optimistic replication allows replicas to diverge. Replicas will reach eventual consistency the next time Alice and Bob sync their replicas with the server state, which only happens when they refresh their chat apps (reload the page).
This seems like kind of a cheat but convergence upon system quiescence is a common strategy to achieve eventual consistency. This relieves us from having to implement an explicit reconciliation policy for the replicas which could be unnecessarily complex for our problem space.
The insufficient real-time support is a limitation of our approach but is good enough for OkCupid’s use case because in a dating app, we don’t expect people to be chatting simultaneously for a long period of seksikГ¤s Kirgisian naiset time like they would in Slack
But if you are building a real-time chat app where simultaneous communication is a common use case, you will need to implement offline detection/polling the latest server data and merge the server data into the replica.
Sub-problem 5: Intention Preservation
All the strategies for implementing collaborative editing tools are guided by a set of principles depending on which consistency model is used.
ensures the execution order of causally dependent operations be the same as their natural cause-effect order during the process of collaboration.
ensures the replicated copies of the shared document be identical at all sites at quiescence (i.e., the final result at the end of a collaborative editing session is consistent across all replicas).
ensures that the effect of executing an operation at remote sites achieves the same effect as executing this operation at the local site at the time of its generation.
Causality preservation and convergence are essential properties of any consistency model to ensure the correctness of the system during and after a collaboration session.
The causally dependent operations include optimistically adding the message with client-generated tempId to the replica, then when the server approves the mutation, replace the optimistic message with the real message with the server-assigned id , including a tombstone for what it was before when it was optimistically added (we will talk about this later in the implementation of the chat app CRDT).