Skip to content

Reference architecture

Multiplayer real-time whiteboard with CRDTs and WebSockets

Collaborative multiplayer web apps in the style of Figma or Miro, built on conflict-free replicated data types (CRDTs) and optimistic canvas rendering.

Talk to an engineer
Custom software service

Design constraints

What the design has to hold to

Targets for the scenario this reference is sized for. A real engagement starts by replacing them with your own numbers.

  • 01Under 50 ms to sync cursors and drawing between collaborators
  • 02Offline-first editing, with conflicts resolved automatically on reconnection
  • 03100+ concurrent collaborators on one shared infinite canvas
  • 04Compact binary deltas to keep WebSocket bandwidth low

Component topology

System components and technologies

Subsystems with separate responsibilities, clear contracts between them and storage that scales on its own. The stack named for each is typical, not mandatory.

Stack topology

Multiplayer real-time whiteboard with CRDTs and WebSockets

Illustrative reference architecture

  1. 01

    Collaborative canvas UI

    WebGL/Canvas rendering of shapes and presence cursors

    Next.js + PixiJS / React Flow

  2. 02

    CRDT state layer

    Shared document changes, merged without conflicts

    Yjs / Automerge

  3. 03

    Multiplayer signaling server

    Room-based WebSocket coordination and ephemeral presence

    Node.js (uWebSockets.js) / Cloudflare Durable Objects

  4. 04

    Document persistence tier

    Binary CRDT state vectors and document snapshots

    PostgreSQL / Amazon S3

Subsystem 01

Collaborative canvas UI

WebGL/Canvas rendering of shapes and presence cursors

Typical stack

Next.js + PixiJS / React Flow

Subsystem 02

CRDT state layer

Shared document changes, merged without conflicts

Typical stack

Yjs / Automerge

Subsystem 03

Multiplayer signaling server

Room-based WebSocket coordination and ephemeral presence

Typical stack

Node.js (uWebSockets.js) / Cloudflare Durable Objects

Subsystem 04

Document persistence tier

Binary CRDT state vectors and document snapshots

Typical stack

PostgreSQL / Amazon S3

Data lifecycle

End-to-end data flow

  1. A user opens a shared canvas; the WebSocket connects to the room's Cloudflare Durable Object.

  2. The room sends the binary Yjs state vector, and the client loads the canvas into memory.

  3. Moving a shape updates the local Yjs document optimistically and re-renders within the next frame.

  4. Yjs encodes the change as a binary delta and broadcasts it to the room's peers.

  5. Peers merge the delta deterministically, so every client converges on the same state.

Reliability and resilience

Failure modes and how each is contained

Failure mode 01

WebSocket drops in mobile browsers

Mitigation

Persist local edits in IndexedDB; Yjs merges the offline changes on reconnection.

Failure mode 02

Document memory growth

Mitigation

Periodically compact CRDT history into snapshots stored in S3.

Failure mode 03

Cursor presence flooding bandwidth

Mitigation

Throttle cursor updates to 30 per second and send them as ephemeral messages that are never persisted.

Questions

What teams ask about this design

Operational Transformation, used by Google Docs, relies on a central server to order operations. CRDTs merge concurrent changes on any device without central coordination.

Every change carries a unique client ID and a logical clock, and Yjs orders concurrent edits deterministically from them, so all clients converge to the same state.

Planning a system like this?

Send us your requirements, expected load and budget. We'll reply within one business day with an honest read on the design, and on whether we're the right team to build it.

Request an architecture review