Architecting Real-Time Vector Collaboration: The Figma Synchronization Model

The Challenge of Concurrent Vector Editing

Building a collaborative design tool requires solving a fundamental conflict: the need for immediate, zero-latency local feedback versus the requirement for a single, consistent source of truth across multiple global clients. Traditional locking mechanisms—where one user "owns" an object while editing—destroy the fluid nature of design work. The goal is to allow multiple users to manipulate the same vector paths simultaneously without the document state diverging into incompatible versions.

The Minimal Viable Architecture

To achieve this, the architecture separates the rendering engine from the synchronization layer. The rendering engine handles the heavy lifting of vector math and GPU acceleration, while the synchronization layer manages the propagation of changes.

The High-Performance Rendering Core

Standard JavaScript is often insufficient for the complex calculations required for thousands of vector nodes. Figma utilizes a core engine written in C++ and compiled to WebAssembly (Wasm). This allows the application to bypass the JavaScript garbage collector for its primary data structures and execute memory-intensive operations at near-native speeds.

The Synchronization Engine

The system avoids heavy centralized locking in favor of an approach inspired by Conflict-free Replicated Data Types (CRDTs). Instead of sending the entire document state, the system transmits incremental updates (deltas). When a user moves a rectangle, the client applies the change locally immediately (optimistic UI) and sends a small operation packet to the server.

Trust and Data Boundaries

While the client handles the rendering, the server remains the authoritative source of truth. This creates a clear boundary for data integrity:

• Client Boundary: Responsible for optimistic updates, local state caching, and Wasm-based rendering. The client does not decide the final sequence of operations.
• Server Boundary: Responsible for sequencing operations, persisting the document state, and broadcasting updates to other connected peers via WebSockets.

This boundary ensures that if two users move the same object to different locations at the exact same millisecond, the server determines the final order of operations, and all clients eventually converge on that same state.

Operational Checks and Verification

To ensure the system is functioning correctly, developers can monitor the interaction between the browser and the server. Since the synchronization happens over WebSockets, the traffic is continuous rather than request-response based.

Diagnostic Verification

You can verify the synchronization behavior using browser developer tools:

1. Network Analysis: Open the Network tab and filter by WS (WebSockets). Observe the frames being sent and received during a move operation. You should see small, frequent binary frames rather than large JSON payloads.
2. Performance Profiling: Use the Performance tab to record a session while zooming or panning. Look for execution time spent in Wasm modules, which indicates the C++ engine is handling the canvas calculations rather than the main JS thread.
3. Connectivity Testing: Toggle the Offline mode in the Network tab. Perform several edits, then toggle back to Online. The client must reconcile its local optimistic state with the server's authoritative sequence without losing data.

Failure Modes and Constraints

No real-time system is without trade-offs. The current architecture faces specific risks:

Failure Mode	Impact	Mitigation
Network Partition	Temporary state divergence between peers.	Server-side sequencing and client-side reconciliation upon reconnection.
Wasm Memory Leak	Browser tab crashes during long sessions.	Manual memory management within C++ to avoid leaking outside the JS heap.
Object Explosion	Synchronization overhead increases linearly with object count.	Implementing document snapshots to allow new clients to "jump" to the current state.

Conditions for Architectural Change

The current design is optimized for 2D vector manipulation. The architecture would require a fundamental shift if the following requirements emerged:

• Full Offline-First Mode: If the product required days of offline work with complex branching and merging (like Git), a move toward a full peer-to-peer CRDT model would be necessary to avoid the server bottleneck.
• Extremely High-Density Data: If documents grew to millions of objects, the current WebSocket broadcasting model would saturate client bandwidth, requiring a spatial partitioning system (only syncing objects currently in the user's viewport).