The essential question of Real-time Collaboration: How does Figma handle multiplayer editing?

In the realm of modern Web software engineering, Figma’s seamless multiplayer collaboration has redefined design tool standards, making its real-time editing implementation a staple question in advanced System Design interviews. While CRDT (Conflict-free Replicated Data Types) is often cited as the standard solution, the underlying engineering is far more sophisticated than mere algorithm selection. Figma’s core breakthrough lies in abandoning traditional screen-sharing pixel streaming for an efficient data synchronization mechanism based on Object Trees and Property Deltas. Unlike text editors like Google Docs that rely on Operational Transformation (OT), Figma deals with non-linear graphical objects identified by UUIDs; this drove the team to forgo central server-based complex ordering in favor of an eventual consistency model suited for distributed environments.

Core Principle Revealed: The "Mastermind" Behind Figma's Multiplayer Collaboration is CRDT

In System Design interviews, when an interviewer asks "How does Figma implement conflict-free simultaneous editing by multiple people," the core keyword is CRDT.

CRDT (Conflict-free Replicated Data Types) is a data structure used in distributed systems that allows multiple replicas (Clients) in a network to modify data independently and concurrently without a central lock, and automatically merges these modifications through mathematical rules, ultimately ensuring the data state of all replicas is consistent (Eventual Consistency).

Not "Screen Sharing," But "Data Synchronization"

The first step in understanding Figma's collaboration mechanism is to distinguish it from traditional remote desktop or screen sharing.

• Screen Sharing (Pixel Streaming): Transmits video streams or pixel frames. It has extremely high bandwidth requirements and cannot obtain semantic information of objects (cannot select others' layers).
• Figma's Approach (Property Deltas): Transmits extremely lightweight property changes (Deltas).
  When you move a rectangle on the canvas, Figma does not send the entire file, but sends a command similar to update(layer_id, property="x", value=100) to the server via WebSocket. The local rendering engine is responsible for drawing the interface at 60FPS, while the network layer is only responsible for synchronizing these tiny data changes.

Three Major Engineering Advantages Brought by CRDT

The official Figma engineering team has detailed that its multiplayer collaboration technology was deeply inspired by CRDT concepts. This technology choice directly solved three major pain points of traditional collaboration tools:

1. Lock-free Real-time Availability
   The system does not need to "lock" files or layers. When User A modifies a layer color, they do not need to wait for User B to release permissions. All clients can write at any time; this "optimistic" concurrency mode is the foundation of a smooth experience.
2. Native Offline Support
   This is one of the most powerful features of CRDT. Since CRDT's merge logic is based on the mathematical properties of the data structure itself, rather than relying on real-time arbitration by a central server, users can continue editing while offline. Once the network is restored, the locally accumulated sequence of operations (Operations) will automatically sync and merge into the main document, achieving seamless reconnection.
3. Automatic Conflict Resolution
   In a distributed environment, conflicts are inevitable (e.g., two people modifying the color of the same rectangle at the same time). CRDT guarantees that as long as all clients receive the same set of operations, regardless of the order of receipt, they can ultimately calculate the same state. Figma employs specific strategies for different properties (such as Last-Writer-Wins), ensuring the system can automatically converge without popping up a "Version conflict, please merge manually" dialog box.

Why CRDT? A Technical Comparison with the OT Algorithm

In the realm of real-time collaboration, Operational Transformation (OT) was once the undisputed industry standard, serving as the cornerstone for collaborative document editors like Google Docs. However, when Figma decided to build a browser-based multiplayer design tool, they did not blindly follow OT; instead, they chose CRDT (Conflict-free Replicated Data Types) and its variants as their technical foundation.

Behind this technical choice lies the fundamental difference in data models between text editing and graphic design, as well as a trade-off regarding engineering complexity.

1. Linear Stream vs. Object Properties: The Limitations of OT

OT algorithms excel at handling Linear Data Streams. In Google Docs, a document is essentially a long string.

• Scenario: User A inserts "Hello" at the 5th character, while User B simultaneously deletes the 3rd character.
• OT's Solution: The algorithm must use complex transformation logic to adjust index positions, ensuring that both operations yield the same result after being applied on different clients.

However, Figma's design files are not linear strings but complex collections composed of independent objects.

• Scenario: User A modifies the color of "Layer 1", while User B modifies the X-axis coordinate of "Layer 1".
• Figma's Solution: These two operations target different properties of the same object; logically, they do not interfere with each other.

If one were to forcibly use OT to handle this two-dimensional or even multi-dimensional object hierarchy, engineering complexity would rise exponentially. As mentioned in How Figma handles edit conflicts, for non-text tools, OT often appears to be "overkill." What Figma needs to handle are atomic changes to object properties, not relative position transformations of a character stream.

2. Central Authority vs. Distributed Consistency

OT algorithms typically rely on a Central Authority to determine the order of operations.

• OT Mode: All operations must be "stamped" and transformed by the server, which acts as the absolute center of truth. This significantly degrades user experience in high-latency or offline scenarios.
• CRDT Mode: CRDT was designed from the outset to support distributed systems and offline-first scenarios. It allows different clients to apply changes locally first, then automatically merge them through mathematically commutative rules to achieve Eventual Consistency, without relying on a central server for complex conflict arbitration.

3. Engineering Trade-offs: Last-Writer-Wins (LWW)

In specific engineering implementation, Figma adopted a simplified CRDT strategy, namely the Last-Writer-Wins (LWW) strategy for object properties.

This strategy means that if two designers modify the color of the same rectangle almost simultaneously, Figma will not ask users to "resolve conflicts" like Git does, but will directly adopt the value that arrives last. For visual design tools, this approach aligns with user intuition and avoids the complex intention preservation issues associated with OT.

By abandoning the obsession with "character-level precise ordering" and embracing eventual consistency for object properties, Figma successfully shifted the performance bottleneck of real-time collaboration from algorithmic computation to pure network transmission.

Figma's Data Structure: Object Tree Model

To understand why Figma can achieve efficient collaboration through CRDT, one must first understand its underlying data model. Unlike document tools like Google Docs that process linear "character streams," Figma processes a hierarchical Object Tree.

1. DOM-like Tree Structure and UUID

Figma's document structure is conceptually very similar to the browser's DOM tree, consisting of Page, Frame, Group, and Layer (such as rectangles, text, vector paths).

However, in distributed systems, the most critical design lies in Identity. In Figma, every object is assigned a globally unique UUID upon creation. This is distinctly different from the "array index" or "line number" typically relied upon by text editors. No matter where the object is moved in the layer panel, its UUID remains unchanged. This allows the CRDT algorithm to precisely locate the target object without needing to care about its current relative position.

2. Property-based Atomic Updates (Property Deltas)

Based on this object model, every edit operation in Figma is actually a Property Delta targeting a specific UUID object, rather than resending the entire file or viewport pixels.

For example, when a user moves a rectangle 10px to the right, the message sent by the client to the server is not "update screen area," but a JSON-like instruction:

{
  "op": "update_property",
  "objectId": "550e8400-e29b-...",
  "property": "x",
  "value": 150
}

The advantage of this data structure lies in its extremely high orthogonality:

• If User A modifies the color of Layer X;
• At the same time, User B modifies the position of Layer Y;
• Or User C modifies the corner radius of Layer X;

Since these operations act on different objects or different properties of the same object, they are mathematically non-interfering and can be applied directly without complex conflict merging logic. As explained in the official Figma blog, Figma's server only needs to track the "latest value" (Last-Writer-Wins) of each property of each object to ensure eventual consistency.

3. Handling Complex Parent-Child Relationships

The trickiest part of the object tree model lies in structural changes, specifically changes in "parent-child relationships" (Reparenting). For example, dragging a layer from "Frame A" into "Frame B".

In Figma's data structure, the parent-child relationship is also treated as a property (e.g., parent_id). However, this introduces a potential logical trap: if User A sets Layer P as the parent of Layer C, while User B simultaneously sets Layer C as the parent of Layer P, it results in a "circular reference" (Cycle), causing the rendering engine to crash.

To solve this problem, Figma did not simply rely on generic CRDT libraries but instead customized rules for this 2D scenario to ensure the integrity of the tree structure is not destroyed by concurrent operations. This design of abstracting "visual hierarchy" into a "property database" is precisely the engineering cornerstone that allows Figma to support large-scale multiplayer real-time editing.

Conflict Resolution in Practice and Offline Synchronization Mechanisms

In the design of multiplayer real-time collaboration systems, the thorniest issue is often not "how to transmit data" but "how to handle inconsistencies." When two designers modify the same layer simultaneously, or when a user continues editing after losing internet access in an elevator, the system must ensure that the document state seen by everyone is ultimately consistent. This is the principle of Eventual Consistency in distributed systems.

Figma did not adopt the complex OT (Operational Transformation) algorithms used by Google Docs to handle all conflicts. Instead, it combined the design philosophy of CRDTs (Conflict-free Replicated Data Types) with the arbitration capabilities of a centralized server to build a synchronization mechanism that is both lightweight and robust.

1. Property-Level Conflicts: Last-Write-Wins (LWW) Strategy

For the vast majority of design operations, such as modifying color, adjusting opacity, or changing position, Figma treats them as simple property updates. Each Object has a unique UUID, while Properties are key-value pairs on the object.

When a conflict occurs—for example, User A changes a button to red, while User B almost simultaneously changes it to blue—Figma adopts the Last-Write-Wins (LWW) strategy.

According to the explanation by the Figma engineering team, the server is the final arbiter of the event sequence. Figma does not need to rely on complex distributed clock synchronization; instead, the order in which the server receives messages determines which value is the "latest."

• Scenario: Users A and B modify the same property.
• Process: The server receives A's request and updates the value to red; subsequently, it receives B's request, updates the value to blue, and broadcasts this to all clients.
• Result: All clients ultimately display blue.

Although this strategy is simple, it is very effective in high-frequency, low-latency scenarios because it avoids complex merge logic (Merge Hell). For visual properties, users generally accept the intuition that "the last operation takes effect."

2. Structural Conflicts and CRDT Inspiration

More complex than property modifications are changes to the Tree Structure. For example: User A deletes a Group, while User B is adding a layer to that Group. If handled improperly, this could lead to data corruption or layers hanging "like ghosts."

Figma draws on the mathematical properties of CRDTs to ensure data structure convergence but makes pragmatic adjustments for performance and storage efficiency:

• Hierarchy as Property: The Parent-Child relationship of objects is treated as a special property (e.g., parent_id).
• Object Liveness: The creation and deletion of objects are treated as explicit operations.
• Deletion Priority: If a parent object is deleted, according to Figma's logic, all data associated with that object (including its properties and child references) is removed from the server. This means that in the aforementioned conflict scenario, if the layer newly added by User B attempts to mount onto a Group ID that has already been deleted, the operation will ultimately be corrected or deemed invalid, thereby ensuring the integrity of the document tree.

It is worth noting that to prevent the document from bloating indefinitely, Figma does not permanently retain "Tombstones" (placeholders for deleted objects) on the server. Instead, the data of the deletion operation is moved into the Undo Buffer of the client that performed the operation. If that user undoes the deletion, the client is responsible for restoring the object and its properties. This design greatly optimizes server storage pressure while ensuring consistency.

3. Offline Support and the "Tunnel" Scenario

Real-world network environments are unreliable. When a user takes their laptop into a tunnel with no signal, Figma still allows for smooth editing. This experience relies on Optimistic UI and reconnection synchronization mechanisms.

1. Optimistic Updates: When a user operates in an offline state, the client immediately applies the changes to keep the interface responsive, while simultaneously storing these operations in a local queue to be sent.
2. Prediction and Correction: The client considers its current state to be the "latest" predicted value.
3. Reconnection Merge: When the network recovers, the client sends the changes in the queue to the server in a batch.

• • If the server did not receive conflicting changes for the same object during the disconnection, the local changes are accepted and broadcast.
  • If a conflict occurred (e.g., an object modified offline was deleted by another online user), the latest state returned by the server overrides the local predicted state.

This mechanism ensures that users do not feel any lag during network fluctuations, and after the network recovers, the system can automatically "catch up" to the latest consistent state without requiring the user to manually resolve merge conflicts. As stated in a technical analysis on LinkedIn, this strategy of "atomic synchronization" and "ignoring conflicts" is precisely the key to Figma's ability to achieve silky-smooth multiplayer collaboration—it sacrifices data retention in some extreme cases (being overwritten) in exchange for ultimate performance and user experience.

Beyond Algorithms: WebGL Rendering and Performance Architecture

Although CRDT (Conflict-free Replicated Data Types) solves the logical puzzle of "whose data is correct," for users, the smoothness of real-time collaboration depends not only on the accuracy of data synchronization but also on rendering performance. If data sync is perfect but the interface is only 10fps, the collaboration experience is still unusable. The core reason why Figma can achieve performance comparable to native applications in the browser lies in its departure from the traditional DOM rendering path, adopting a high-performance architecture combining WebGL and WebAssembly (WASM).

Why is the DOM Unsuitable for Large-Scale Collaboration?

In traditional Web development, we usually use the HTML DOM to build interfaces. However, for a professional vector design tool, the overhead of the DOM is too large. If every layer corresponds to a DOM node, when a design contains thousands or tens of thousands of layers, the browser's Layout (reflow) and Paint (repaint) computational load will rise exponentially.

To break through this limitation, Figma chose a more hardcore route: rendering directly using WebGL.

• GPU Acceleration: Figma wrote a custom rendering engine, directly calling the GPU to draw 2D vector graphics instead of relying on the browser's rendering pipeline. This allows it to easily handle complex scenes containing tens of thousands of objects while maintaining a smoothness of 60fps.
• Virtualized Rendering: Just like map applications, Figma's canvas is theoretically infinite. The engine only renders content visible within the Viewport. Through "tile-based rendering" technology, it ensures that no matter how large the file is, zooming and panning operations remain silky smooth.

C++ and WebAssembly: Separating Logic and View

Behind high-performance rendering lies a more low-level architectural decision. Figma's core logic (including graphics algorithms and data structure processing) is not written directly in JavaScript, but primarily in C++, and runs in the browser via WebAssembly (WASM).

This architecture brings two key advantages:

1. Headless Core:
   Since the core logic is written in C++ and does not depend on a specific rendering platform (like the DOM), this allows Figma's engine to be a "headless" pure computation module. This means the same codebase can run on the browser side, the server side, or even be compiled as part of a native application. This consistency is crucial for multi-user collaboration because it guarantees that the data processing results on all ends are strictly consistent.
2. Extreme Memory and Computational Efficiency:
   WASM allows code to run at near-native speeds, which is critical for handling complex CRDT merge operations and real-time rendering loops. However, developers should also understand the physical limitations of this architecture during interviews: browsers typically have a hard cap on WASM memory allocation (usually a 2GB active memory limit). When a collaboration file is too large, causing memory usage to approach this threshold, users may experience performance degradation or even crashes. This is a system-level constraint imposed by the browser sandbox mechanism.

Architecture Summary: The Final Piece of the Collaboration Puzzle

When discussing Figma's architecture in an interview, it can be summarized as a "Dual-Layer Architecture":

• Logic Layer: Written in C++ and run via WASM, responsible for handling CRDT synchronization, conflict resolution, and document structure operations. It is the single source of truth.
• Presentation Layer: A custom renderer based on WebGL, responsible for drawing data from the logic layer onto the Canvas at extremely high frame rates.

This separation ensures that even when network fluctuations cause CRDT synchronization delays, the rendering thread can still run independently, ensuring that user local interactions (such as zooming and selecting) do not stutter. It is precisely this deep integration of algorithms and rendering architecture that creates the unique experience of "cloud collaboration that feels like a local application."

Summary: System Design Lessons Learned from Figma's Architecture

In system design interviews, when an interviewer asks "How to design a real-time collaboration system," Figma's architecture provides a textbook-level reference answer. This is not just about choosing between WebSocket or HTTP long-polling, but about how to solve the impossible triangle of Consistency, Availability, and Performance through a combination of underlying technologies.

Here are the key lessons worth emphasizing in technical interviews or architecture reviews when reviewing Figma's architecture:

1. The "Three Pillars" of the Core Tech Stack

Figma's success does not rely on a single technology, but on the deep integration of three core technologies. When answering related design questions, this can be summarized into the following architectural layers:

• Data Layer (CRDTs): Solves the "who calls the shots" problem. Figma uses a strategy inspired by CRDT (Conflict-free Replicated Data Types) to handle object property conflicts (e.g., two users modifying a color simultaneously), ensuring that all clients automatically converge to a final consistent state after reconnecting from offline, without the need for complex central locking mechanisms.
• Logic Layer (C++ & WebAssembly): Solves the "browser performance bottleneck" problem. To reuse high-performance graphics algorithms on the Web, Figma wrote the editor's core logic in C++ and runs it in the browser via WebAssembly. This "Headless Core" design decouples the logic layer from the view layer, ensuring consistency across multiple platforms.
• Rendering Layer (WebGL): Solves the "DOM is too slow" problem. Unlike traditional DOM manipulation, Figma utilizes the GPU directly for drawing, ensuring smooth 60fps performance even when handling thousands of layers.

2. Decision Rule: When to Choose OT and When to Choose CRDT?

In system design, blindly stacking technical jargon is a major taboo. You need to demonstrate the ability to weigh technical choices. For the selection of collaboration algorithms, you can use the following Rule of Thumb:

TABLEBLOCK1
| Weak Network/Offline First | CRDT | CRDT inherently supports decentralization and offline submission; clients can accumulate operations in a local queue and automatically merge them after connecting to the network. | Local-first software

3. The Ultimate Trade-off in System Design: Conservation of Complexity

Figma's architecture demonstrates an important engineering philosophy: for simplicity in user experience, one must accept complexity in implementation.

Traditional Web development patterns tend to rely on the browser DOM and off-the-shelf frameworks, which is fast in the early stages of development but exposes complexity to the user when handling high-concurrency collaboration (e.g., frequent loading spinners, conflict pop-ups). Figma chose an extremely difficult path—developing its own rendering engine and synchronization protocol. As industry analysis points out, modern high-performance applications (such as Linear, Superhuman, Figma) tend to build their own Sync Engines, treating data synchronization as a persistence buffer layer independent of the UI.

Interview Bonus Point:
When summarizing, you can mention the concept of "complexity transfer." By introducing CRDT and WASM, Figma transferred the complexity of handling network latency and rendering performance from the "user side" to the "architecture side." For engineers, this means that when designing systems, we should not just focus on the "easiest to implement" solution, but on the solution that "best supports business scale"—even if it means reinventing the wheel.