Blog 12 — Figma: How Multiplayer Technology Works

C

Qubits of DPK

March 21, 2026

Core Case Studies
Source: https://www.figma.com/blog/how-figmas-multiplayer-technology-works/
Core Concept: WebSockets vs Long Polling vs SSE, CRDT (Conflict-free Replicated Data Type), Real-time conflict resolution
Why SDE-2 Critical: Real-time collab is a separate skill set — knowing CRDT separates you from 90% of candidates
Status: Draft notes ready

Quick Revision

  • Problem: Multiple people edit the same object concurrently.
  • Core pattern: WebSockets, optimistic local updates, and CRDT-style reconciliation.
  • Interview one-liner: Real-time collaboration is about converging state without blocking users.

️ The Core Problem

javascript
QUBITS OF DPK
1Alice and Bob both editing same design simultaneously:
2  Alice moves button to x=100
3  Bob moves button to x=200
4  Both changes arrive at server simultaneously
5
6  Which wins? How do you merge?
7  How do you ensure both see same final state?

Core Concepts

WebSockets vs Long Polling vs SSE

javascript
QUBITS OF DPK
1Long Polling (old approach):
2  Client: "Any updates?" → Server waits → responds when update exists
3  Client immediately asks again
4  Latency: 100-500ms, high overhead
5
6SSE (Server-Sent Events):
7  Server → Client only (one direction)
8  Good for: live scores, stock tickers, notifications
9  Bad for: collaborative editing (need bidirectional)
10
11WebSockets (Figma's choice):
12  Persistent bidirectional connection
13  Client ↔ Server, full duplex
14  Latency: < 50ms
15  Perfect for: real-time collaboration

Operational Transformation (Old Approach — Google Docs)

javascript
QUBITS OF DPK
1Alice inserts 'X' at position 3
2Bob deletes character at position 5
3
4If operations applied in different order → different result!
5OT transforms operation B to account for operation A:
6  B' = transform(B, A)
7  Apply A then B' → same result as B then A'
8
9Problem: Complex, hard to implement correctly for rich documents

CRDT — Conflict-free Replicated Data Type

javascript
QUBITS OF DPK
1Figma's approach: Design data structures where
2  ANY order of operations → SAME final result
3
4Example: Last-Write-Wins Register
5  Alice sets button.x = 100 at timestamp T1
6  Bob sets button.x = 200 at timestamp T2 (T2 > T1)
7  → Both operations commute → winner = highest timestamp
8  → ALWAYS resolves to 200 regardless of order received
9
10Example: Grow-only Counter
11  Alice increments likes: +1
12  Bob increments likes: +1
13  → Merge = sum of all increments = +2
14  → Works even if operations arrive out of order

Figma's Actual Architecture

javascript
QUBITS OF DPK
1Client sends operation → WebSocket → Server
2  Server applies operation to canonical state
3  Server broadcasts to ALL other clients
4  Server stores operation in log (for reconnection)
5
6Client also applies operation locally (optimistic update)
7  → UI feels instant, no waiting for server roundtrip
8  → If server sends back correction → reconcile
9
10Client reconnects after disconnect:
11  Server replays all missed operations from log
12  Client applies them in order → syncs to current state

Scale Achieved

5 Interview Questions This Blog Unlocks

Q1. Design Google Docs / collaborative editing

Answer: WebSockets for bidirectional real-time communication. CRDT or OT for conflict resolution. Optimistic local updates for responsiveness. Server as source of truth — broadcasts operations to all clients. Operation log for reconnection recovery. Presence indicators via heartbeat messages.

Q2. What is the difference between WebSockets and HTTP?

Answer: HTTP is request-response — client must initiate every communication. WebSocket is persistent bidirectional — server can push data anytime. HTTP: new TCP connection per request (overhead). WebSocket: one TCP connection maintained. For real-time features, WebSocket latency is 10x lower.

Q3. What is CRDT and why is it better than locking for collaboration?

Answer: CRDT = data structure where concurrent operations always merge to the same result without coordination. No locks needed. Alice and Bob can both edit offline → sync later → guaranteed consistent merge. Locking would block one user while other edits — terrible UX for collaboration.

Q4. What is optimistic UI update and what's the risk?

Answer: Apply operation locally before server confirms. UI feels instant. Risk: server might reject/transform the operation. Solution: server sends back canonical state, client reconciles (OT/CRDT handles this). Trade-off: occasional visible cursor jump vs waiting 100ms for every keystroke.

Q5. How does Figma handle a user who disconnects and reconnects?

Answer: Server maintains an operation log per document. On reconnect, client sends its last known sequence number. Server replays all operations since that sequence number. Client applies them in order. Result: seamless sync to current state as if never disconnected.

Key Engineering Lessons