How Figma's Multiplayer Technology Works?

Blog Link: How Figma's Multiplayer Technology Works

Context

• This blog was written in 2019 when Figma wanted to implement multiplayer technology. At the time, no existing technology fully met the use case Figma was trying to achieve. But from the Product perspective, they saw huge potential in this feature, people will no longer have to share copies of files, instead, they can share live links without disrupting the creator of the document.

Evaluation of the Approach

• Figma is using WebSockets for syncing connections.

• They had two options to guarantee sync consistency: Operational Transformation (OT) and Conflict-Free Replicated Data Types (CRDTs) to implement it. Figma's use case didn't align well with OT, so they decided to use an approach that various CRDT models propose.

• CRDTs are designed for decentralized systems where there is no single central authority to decide what the final state should be and provide eventual consistency.

• Figma wanted to sync updates on documents, Every Figma document is a tree of objects, similar to the HTML DOM. Each object has an ID and collection of properties with values. (eg. Map>)

Syncing Object Properties

• If multiple people are updating, It's essential to take some cases into account

  • Different property on the same object => No conflict

  • Different property on the different Object => No conflict

  • Same property on the different Object => No conflict

  • Same property on the same object => Conflict (In this case, It will consider the last value that was sent to the server, this approach is similar to last-writer-wins-register in CRDT).

• All the changes are atomic, eg. If the current value is B, User 1 changes to AB at the same User 2 changes to BC, at the end result will be either AB or BC but never ABC. While either of them is ok for Figma they decided to go with eventual consistency.

• They remove flickering behavior by discarding property changes coming form the server if there is a freshly updated property found.

Syncing Object creation and removal

• Figma doesn't allow applying property if their object doesn't exist. If someone deletes the object, it removes all the properties connected with that object too.

• In case the User undoes the changes, Figma has an undo buffer to bring back object and their respective properties.

• The generation of a Unique ID is delegated to the client to ensure no two clients will ever generate the same object ID. The main reason behind is that "Figma provides offline support and syncs back to server when network connection available".

Syncing Trees of Objects

• This is the most complicated part of their multiplayer system. They need to make sure of the following two goals:

  • Re-parenting an object shouldn't conflict with changes to different properties on those objects. (eg. User 1 changes the object color, User 2 re-parenting the same object => these both should succeed)

  • Two concurrent re-parenting should not result in two copies of that object in separate places in the tree.

• The naive approach is: deleting the object and recreating it somewhere with a new ID, This won't work for Figma because concurrent edits need to work.

• The solution that Figma adopted was creating a parent-child relationship and storing a link to the parent in the child object. In this way, object identity will be preserved. This approach will form directed edges on a graph, which led to another problem of circular dependency. A-> B, B->A which forms a cycle.

• Of course, the Server should be the main source of truth, Figma found a way to ensure no cycle forms on the server and in case the client changes form a cycle on the server, It will basically reject the change.

Implementing Undo

• Figma had a lot of trouble until they settled on a principle to help guide them: if someone undo a lot, copy something, and redo it back to the present (common operation), the document should not change. In Multiplayer it may end up overwriting what other people did next. This is why in Figma an undo operation modifies redo history and visa versa.

That's it! I hope you will find this summary helpful, I highly recommend reading the actual article!