How to Design Figma in a System Design Interview: CRDTs, WebSockets & Real-Time Sync (2026)

The first 5 minutes of any system design interview should be spent scoping the problem. Don't start drawing boxes until you've aligned on requirements. For Figma specifically:

What are the functional requirements for a collaborative design tool like Figma?

• Multiple users can simultaneously edit a shared canvas (shapes, text, images).
• Each user's cursor position is visible to all other participants in real time.
• Changes from any user propagate to all other users with sub-200ms latency.
• Documents are persisted durably and can be recovered after disconnection.
• Users can comment on specific layers or coordinates.
• Full version history with the ability to restore previous states.

What non-functional requirements does a real-time collaborative editor demand?

• Scale: Support 1 million concurrent users across documents.
• Latency: Cursor position updates must arrive within 50ms for users in the same region.
• Consistency: All users must converge to the same document state eventually (strong eventual consistency).
• Availability: 99.99% uptime — brief regional outages should not corrupt documents.

Step 2: The Core Conflict — CRDTs vs. Operational Transformation (OT)

This is the most intellectually demanding part of the interview. How do you ensure that if User A inserts a shape at position (100, 200) and User B simultaneously moves the same shape to position (150, 250), both users converge to the same final state?

How does Operational Transformation (OT) resolve conflicts in Google Docs?

OT is a centralized, server-coordinated conflict resolution strategy. Every operation (insert character, move element, resize shape) is sent to a central server as a transformation function rather than an absolute state. The server applies a transformation function that adjusts operations based on concurrent concurrent operations that happened before them:

• User A sends: "Insert 'Hello' at index 0"
• User B sends: "Insert 'World' at index 0" (concurrent)
• Server applies A first, then transforms B's operation: "Insert 'World' at index 6" (after 'Hello ')
• Server broadcasts the transformed operations to all clients.

Limitation: OT requires all operations to pass through a single central server. At global scale with millions of users, this central transformation server becomes a single point of failure and a throughput bottleneck.

How do CRDTs (Conflict-Free Replicated Data Types) power Figma's real-time sync?

CRDTs are mathematical data structures designed to resolve conflicts by construction. The algebraic properties of a CRDT guarantee that applying operations in any order always produces the same result — no coordination server required. Figma's document structure uses a specialized tree CRDT called a Hybrid Logical Clock (HLC) CRDT tree:

• Every node (layer, shape, frame) has a globally unique CRDT identifier composed of a logical timestamp and a random node ID.
• When two users delete and re-insert the same node simultaneously, the CRDT's merge function deterministically picks a winner based on timestamp ordering, without any round-trip to a central arbitration server.
• This enables Figma's peer-assisted synchronization — clients can sync directly with each other during edge server outages, then reconcile with the central store when connectivity is restored.

// Simplified CRDT sequence for element positioning
// Each update carries { elementId, position, logicalClock, authorId }
{
  "type": "MOVE_ELEMENT",
  "elementId": "rect-a4f2",
  "newPosition": { "x": 200, "y": 350 },
  "hlcTimestamp": "2026-05-28T12:00:00.001Z:node-7e3f", // HLC + nodeId
  "authorId": "user-01"
}
// If a concurrent operation arrives with the same elementId but
// a different hlcTimestamp, the higher HLC value wins (last-write-wins per element)

Step 3: Networking Architecture — WebSockets, WebRTC, and WebTransport

How do you synchronize cursor positions across 20+ users at 60fps?

Cursor position updates happen up to 60 times per second per user. A document with 20 simultaneous users generates 1,200 cursor events per second. These are not business-critical operations — dropping 1 in 5 cursor packets is invisible to users. For this tier, we use WebTransport over HTTP/3 (QUIC). Because QUIC is UDP-based, a single dropped packet doesn't stall the entire stream. The cursor just jumps to the next received position smoothly.

Why do document mutations require WebSockets instead of WebTransport?

Shape insertions, deletions, property changes, and layer moves are infrequent but must be delivered reliably. For these, we use persistent WebSocket connections over TCP. WebSockets provide bidirectional, ordered, guaranteed delivery — at the cost of head-of-line blocking if a packet is lost. For document mutations, this trade-off is acceptable because the frequency is low and ordering matters.

What does the high-level architecture of a Figma-like system look like?

Users (Global)
    │
    ▼
[Cloudflare Workers / Global Edge Layer]
    │                    │
    ▼                    ▼
WebSocket Server     WebTransport Server
(Doc mutations)      (Cursor positions)
    │                    │
    └────────┬───────────┘
             ▼
      [Redis Pub/Sub Cluster]
      (Room-level broadcast bus)
             │
             ▼
    [CRDT Merge Engine]
    (Resolve conflicts server-side)
             │
             ▼
    [PostgreSQL — Document Snapshots]
    [S3 — Assets (images, fonts)]
    [Redis — Ephemeral cursor state]

Step 4: Presence System — Who is Currently Viewing This Document?

Tracking which users are currently inside a specific document is a classic distributed presence problem. Our architecture uses the following pattern:

1. On connection: Each user sends a "join room" event. The WebSocket server writes the user's session to a Redis Hash: presence:{docId} → { userId: lastHeartbeatTimestamp }.
2. Heartbeat: Every 5 seconds, the client sends a lightweight heartbeat ping. The server refreshes the Redis TTL for that user's presence entry.
3. On disconnect or missed heartbeat: Redis TTL expires (within 10 seconds) and the user is automatically purged from the presence map. The system broadcasts a "user left" event to all connected collaborators.

Step 5: Persistence & Version History

Raw CRDT event logs grow unboundedly. A large Figma document with 6 months of history might have millions of events. Our storage strategy uses a two-tier approach:

How do you handle real-time event replay for reconnecting users?

All CRDT operations are appended to a time-series log in Apache Kafka. This enables real-time event replay for users who reconnect after a brief disconnection — they can catch up by replaying events from their last known position in the Kafka offset.

Why are periodic document snapshots critical for onboarding new collaborators?

Every 15 minutes, a background job runs the CRDT merge algorithm across the event log and writes a full document snapshot as a JSON blob to PostgreSQL. This snapshot becomes the "base state" for new users who join the document for the first time, preventing them from having to replay thousands of events.

How should image and font assets be stored and delivered globally?

All image uploads, custom fonts, and vector assets are stored in S3. A CloudFront CDN sits in front of S3, ensuring low-latency delivery globally. Asset URLs are embedded in the document CRDT as stable references — the CDN handles the delivery optimization independently.

Step 6: Scaling to 1 Million Concurrent Users

A single WebSocket server can handle approximately 50,000–100,000 concurrent connections, depending on message frequency. At 1 million concurrent users across all documents:

• Horizontal scaling: Deploy 20+ WebSocket server instances behind a Layer 4 load balancer (with sticky sessions per document room).
• Room sharding: Each document room is "pinned" to a specific WebSocket server instance. All users in a given document connect to the same server, minimizing inter-server Pub/Sub overhead.
• Redis Cluster: Shard the presence and event data across a Redis cluster with 6 nodes (3 primary + 3 replicas), ensuring no single Redis node becomes a bottleneck.
• Global edge replication: Deploy WebSocket server clusters in at least 5 geographic regions (US-East, US-West, EU-West, Asia-Pacific, India). Users connect to the nearest region, reducing baseline latency by 60-80ms for international users.

Continue Mastering System Design

If you found this Figma deep-dive valuable, these related guides will strengthen your system design arsenal:

• Mastering System Design: The Ultimate Guide to API Rate Limiting — another frequently asked system design question covering token bucket, sliding window, and distributed rate limiting.
• Top 5 System Design Interview Questions for 2026 — the five most commonly asked system design questions across FAANG loops, with full architecture breakdowns.
• System Design Masterclass 2026: Scalability Patterns — database sharding, message queues, CAP theorem, and distributed consensus.