How do you implement local-first collaborative editing without the unbounded memory growth inherent to CRDTs crashing the client?

Short answer

CRDTs make local-first collaborative editing possible by letting replicas merge concurrent edits without a central arbiter. The hard production work is bounding metadata growth, garbage-collecting tombstones safely, syncing deltas efficiently, and keeping the editor UI responsive.

The operational transformation bottleneck

Traditional collaborative editing relies heavily on Operational Transformation (OT), a centralized, authoritative server to resolve concurrent edits. This model is fundamentally hostile to local-first philosophies and offline capabilities. The modern approach adopts Conflict-free Replicated Data Types (CRDTs) to handle distributed state synchronization. This empowers clients to edit documents entirely offline, accumulating changes independently, and mathematically guaranteeing conflict-free merges upon reconnection, without a central arbiter.

The cost of guaranteeing commutative merges

The rigidity comes from the mathematical requirements of CRDTs. To guarantee commutativity during future merges, a CRDT must maintain an immutable history of every single operation—every character inserted or deleted. This inevitably leads to unbounded memory growth. A seemingly simple thousand-word document generates megabytes of metadata. In a browser environment with strict heap limits, especially on mobile devices, this naive implementation guarantees eventual catastrophic failure and crashing tabs.

Taming unbounded memory

Aggressive optimization strategies are mandatory. Tombstoning deleted characters without purging them is theoretically pure but practically disastrous. A robust architecture implements sophisticated garbage collection mechanisms, condensing the operation history and compressing the state once changes are provably synchronized across all active peers.

Navigating the chaotic network layer

Synchronizing this dense state across volatile connections requires a hybrid network topology. WebSockets provide rapid syncing with relay servers when online, but a true local-first system seamlessly falls back to WebRTC for peer-to-peer synchronization when isolated on a local network.

Broadcasting the entire massive document history on every keystroke is unscalable. The synchronization protocol must efficiently calculate the delta—the minimal necessary byte difference between two divergent CRDT states.

Bridging mathematics and reactive UIs

Prolonged offline periods guarantee massive, divergent edits. When a user rewrites an entire chapter offline while a colleague edits the same section, the CRDT must resolve these massive operations gracefully. Furthermore, this complex, abstract tree of unique identifiers must be translated into a performant, observable state model that drives a reactive frontend framework like React, alongside an editor component like ProseMirror. Cursor positions and text selections must be dynamically managed, accurately tracking user intent even as the underlying document text shifts asynchronously due to incoming remote operations.

flowchart TD
    A["Local User Edit"] --> B["Apply to Local CRDT Instance"]
    B --> C["Update Local UI"]
    B --> D["Persist to IndexedDB"]
    B --> E{"Check Network Status"}
    E -- "Online" --> F["Calculate State Delta"]
    F --> G["Broadcast via WebSocket/WebRTC"]
    G --> H["Remote Peer Receives Delta"]
    H --> I["Merge into Remote CRDT"]
    I --> J["Trigger Reactive UI Update"]
    E -- "Offline" --> K["Queue Operations Locally"]
    K --> E

True local-first architecture shifts the source of truth to the edge, requiring profound innovations in data structures and synchronisation protocols to manage the inevitable chaos of disconnected, concurrent collaboration.

© 2026 Preptima. Originally published at preptima.com.