Solving Real Time Collaboration Using Eventual Consistency
The collaboration problem: overwriting each other changes
In traditional online applications, when you make a modification to the state of the object you work on, the change propagates to a central server that holds the “truth”. The server registers the change and sends back a confirmation that the change was indeed applied.
The problem happens when Alice and Bob try to update the same database field at the same time. At this point, there will be a data race and whichever request gets to the database last, will “win”, the other will be discarded. That’s quite a jarring experience especially because round-trip latency of up to a second aren’t unusual (especially on mobile), so Alice might have moved on thinking their change applied, only to realize later on that it was overwritten. This is quite regrettable especially since those two updates aren’t technically conflicting, they are modifying different parts of the same string.
This traditional approach wasn’t designed with real time collaboration in mind and it naturally induces latency and flow challenges, making the collaboration experience worse.
One way to work around the latency and some of the conflict resolutions challenges is to pretend that we don’t need to talk to a server and that all changes are local. This is the approach the Fluid framework chose. Fluid still needs to eventually have all collaborators agree on the current state of our object(s) and has to avoid all conflicts. For that, it relies on eventual consistency provided by distributed data structures.
Fluid abstracts the networking and backend layers so developers can focus on building an user experience by only thinking “local”. There isn’t a centralized canonical data truth to check against anymore, instead all connected users have the data locally and all these users always eventually end up with the exact same data. This “local” approach allows for a zero latency experience while keeping data consistent.
Eventual consistency using special data structures
Example: Alice and Bob are co-editing a document at the same time
Alice and Bob both load a Fluidified application. The User Interface uses Fluid to load and manage the state of its underlying data. The application page has a title for which the initial state is loaded by Fluid from a server, the title reads “hello world!”
Alice edits the title so it reads “hello Alice!”, the change is applied right away to the data structure representing the title and an operation representing the change is sent to the Fluid server to propagate to all connected collaborators.
A new operation is sent to the Fluid server:
Replace characters at position 6, new content: "Alice"
At the very same time, Bob edits the title too. He injects an upside down exclamation mark so the title reads “¡hello world!”. The change is reflected right away on Bob’s screen and an operation is sent to the Fluid server to propagate to the connected collaborators.
A new operation is sent to the Fluid server:
Insert character at position 0, new content: "¡"
Even though Alice and Bob edited the same text at the same time, both saw their change being applied right away and then saw their collaborator changes being applied without any conflicts. They eventually both see the same consistent title.
Summary
By breaking down content into smart linked structures that know how to deal with granular changes, and can handle potential conflicts on each user’s device, users never wait for anything to happen and therefore feel like there isn’t any latency . Those smart structures are referred as Distributed Data Structures (DDSes) in Fluid parlance and are the key to making Fluid feel real time. Fluid offers various DDSes to cover the diverse needs of developers besides working on a collaborative text. Most DDSes link one to one to known structures such as strings, maps or linked lists. Developers can focus solely on the creation of amazing User Experiences and data modeling, the underlying concerns such as connectivity, data transfer and applying of operations and conflict resolutions are handled by the framework.