How Figma Built Its Real‑Time Multi‑User Collaboration Engine

1. Introduction

This article is a Chinese translation and commentary on Evan Wallace’s original blog post, which details the technical implementation of Figma’s multi‑user collaboration features.

2. How Figma’s Multi‑User Collaboration Works

Four years ago, when Figma first started building real‑time collaboration, the team chose to create a custom solution rather than using operational transformation (OT), which was considered too complex for a startup that needed rapid feature delivery.

2.1 Background

Figma uses a client‑server architecture where the web client communicates with a set of servers via WebSockets. Each collaborative document runs in its own server process, and all users editing the document connect to that process. When a document is opened, the client downloads a copy and then synchronizes updates over the WebSocket connection, supporting offline edits that are later merged.

2.2 OTs and CRDTs Influence

Operational transformation drives most text‑based collaborative apps (e.g., Google Docs) but is complex and hard to implement correctly. Figma instead drew inspiration from conflict‑free replicated data types (CRDTs), which guarantee eventual consistency without needing timestamps because the server defines event order.

Grow‑only set: only addition operations are allowed.

Last‑writer‑wins register: the most recent update wins, using peer ID to break ties.

Figma does not use pure CRDTs; instead, it adopts simplified ideas to avoid the overhead of decentralized CRDTs, since a central server can act as the authority.

2.3 Document Structure

Each Figma document is an object tree similar to the HTML DOM, with a single root, pages, and nested layers. Every object has an ID and a set of properties, which can be viewed as a two‑level map Map<ObjectID, Map<Property, Value>> or as rows in a database.

3. Details of the Collaboration System

3.1 Synchronizing Object Properties

The server records the latest value for each object property sent by a client. Conflicts only occur when two clients modify the same property of the same object simultaneously; the server resolves this by keeping the last received value, similar to a last‑writer‑wins register.

3.2 Creating and Deleting Objects

Object creation is treated as a last‑writer‑wins set, while deletion removes all object data from the server. Deleted objects are kept only in the client’s undo buffer, allowing undo without growing server storage.

3.3 Synchronizing the Object Tree

Maintaining a consistent tree structure is challenging, especially when re‑parenting objects. The goals are to avoid conflicts between property changes and re‑parenting, and to prevent duplicate copies of the same object.

Property changes should not conflict with re‑parenting.

Concurrent re‑parenting of the same object should not create two copies.

3.3.1 Cycle Detection

Parent links are directed edges; without constraints they could form cycles (e.g., A becomes B’s child while B becomes A’s child). Such cycles are invalid for a tree.

3.3.2 Figma’s Solution

The server rejects any update that would create a cycle. On the client, temporary cycles may appear until the server’s rejection is received; the client then removes the offending objects from the tree.

3.4 Fractional Indexing for Ordering

Figma stores the order of children using fractional indexing: each child’s position is a fraction between 0 and 1, and inserting between two nodes is done by averaging their positions.

4. Undo/Redo Implementation

In a collaborative setting, undo must consider edits from other users. Figma’s approach modifies the redo history when an undo is performed and vice‑versa, ensuring that the final document state remains unchanged after a sequence of undo‑redo actions.

7. Conclusion

The article highlights several takeaways: CRDT literature is valuable even for centralized systems; visual editors’ collaborative systems are less daunting than they appear; and early research and prototyping are worthwhile investments.