Real-Time Collaborative Apps with CRDTs and WebSockets

For decades, collaborative text editing relied on Operational Transformation (OT) — the technology powering early Google Docs. OT works by transmitting operations (insert, delete) to a central server, which transforms incoming position offsets relative to concurrent operations before broadcasting them to other clients. While effective, OT requires a single authoritative server to compute transformations and maintain strict operation sequencing.

In contrast, CRDTs achieve consistency decentralised without requiring a central server to transform operations. CRDT data structures (such as Yjs or Automerge) attach unique deterministic identifiers — such as fractional index strings or Lamport timestamps — to every element. Because item IDs determine ordering independently of when operations arrive, concurrent updates can be merged in any order on any client to produce the exact same final state.

This structural independence simplifies architecture: the server acts purely as a dumb relay broker or WebSocket router, reducing server CPU utilization and eliminating central bottlenecks. For deeper context on distributed locks and concurrency primitives, explore our comparison of Redis Redlock vs etcd vs ZooKeeper.

CRDT implementations generally fall into two architectural categories: State-based (CvRDT) and Operation-based (CmRDT). Understanding the distinction dictates payload sizes, network protocols, and garbage collection strategies.

State-based CRDTs (Convergent) transmit the full state of the data structure between replicas. Replicas merge incoming full states using a join semi-lattice operator $\\sqcup$ that is commutative ($A \\sqcup B = B \\sqcup A$), associative ($A \\sqcup (B \\sqcup C) = (A \\sqcup B) \\sqcup C$), and idempotent ($A \\sqcup A = A$). State-based CRDTs are resilient against network packet loss or duplication, but bandwidth grows as the total dataset size expands.

Operation-based CRDTs (Commutative) transmit individual fine-grained operations (e.g., 'insert char X at ID 4.2'). Operations must be delivered across the network exactly-once and in causal order. CmRDT payloads are orders of magnitude smaller than full-state transfers, making them ideal for continuous low-latency WebSocket messaging in real-time collaborative text and canvas applications.

To connect clients executing CRDT state updates, applications establish persistent bi-directional WebSocket connections to a pub/sub messaging gateway. Upon connecting, a client exchanges state vectors with the server to determine missing binary updates through a two-step handshake.

First, Client A sends its local State Vector — a compact dictionary summarizing the latest sequence number received for every active client ID. The server compares Client A's vector against the document's canonical state and returns only the missing binary delta updates. Client A applies the updates locally to catch up instantaneously.

Second, as Client A types, local changes are encoded into compact binary update chunks (e.g., using Y.encodeStateAsUpdate) and pushed over the WebSocket connection. The gateway broadcasts the binary update chunk to all other subscribed clients on the document channel. Because CRDT updates are idempotent, network retries or out-of-order deliveries never corrupt state.

A key benefit of CRDT architecture is native support for Local-First / Offline-First operation. When a user loses internet connectivity in a tunnel or airplane, local edits continue writing to an IndexedDB or SQLite storage layer seamlessly.

While offline, the local CRDT engine records all document operations in an immutable local delta log. When network connectivity is restored, the client reconnects to the WebSocket gateway, transmits its accumulated delta log, and fetches any server updates missed during the offline window. Both the client and server execute Y.applyUpdate, converging on the identical document state automatically.

To prevent infinite log growth, systems establish periodic Snapshot Compaction. The server merges historical operation logs into a single base snapshot state, discarding obsolete deletion tombstones while preserving active document structure. For theoretical grounding on network availability trade-offs during partitions, consult our CAP theorem guide.