• Fundamentals: How OT and CRDT actually work
• Trade-offs: Complexity, performance, storage, and latency
• Use cases: Which algorithm fits which problem
• Implementation considerations and popular libraries
• Migration paths and hybrid approaches
• Practical Application

The choice between CRDT and OT defines your editor’s user experience as much as your infrastructure: offline behavior, amount of metadata, and the engineering surface area for correctness and performance are all direct consequences of that decision. Make the wrong call and you spend months on transformation edge-cases or years fighting metadata growth and garbage collection.

The problem you're trying to solve is deceptively simple on the surface: multiple people editing a document. The symptoms in the codebase are familiar — wrong ordering on reconnect, invisible edits that later undo other people's work, unbounded memory growth, or an architecture that forces every write through a central sequencer. Those symptoms point at a mismatch between the collaboration algorithm you chose and the real constraints (offline needs, scale, schema complexity) of your product.

Fundamentals: How OT and CRDT actually work

• Operational Transformation (OT) is a transform-first approach: every user action is expressed as an operation (insert, delete, style-change). When operations arrive out of order they are transformed against concurrent operations so that applying the transformed operation yields the same result on every replica. OT implementations typically rely on a server to sequence operations or on a transformation control algorithm that enforces convergence properties. (interaction-design.org) (ot.js.org)

• Conflict-free Replicated Data Types (CRDTs) encode merge logic in the data structure itself. Operations (or states) commute: replicas can apply updates in any order and still converge to the same final state, as long as all updates are delivered. CRDTs come in state-based and operation-based flavors; sequence CRDTs (RGA, Treedoc, etc.) and JSON/Map CRDTs are the primitives you’ll see in editors and local-first apps. (pages.lip6.fr)

Practical examples (JavaScript):

Yjs (CRDT) — create a shared text and insert locally, immediately reflected in the local state and later merged in the background:

import * as Y from 'yjs'
const ydoc = new Y.Doc()
const ytext = ydoc.getText('doc')
ytext.insert(0, 'Hello — local, instant, and later reconciled')
const update = Y.encodeStateAsUpdate(ydoc) // binary snapshot

Yjs exposes Y.Doc, Y.Text, and efficient binary updates for transport and persistence. (docs.yjs.dev)

ShareDB (OT) — server-backed OT: clients submit atomic ops; the server records and sequences them and transforms incoming ops as needed:

const ShareDB = require('sharedb')
const backend = new ShareDB()
// Server creates document, client submits op:
// doc.submitOp([{retain: 5}, {insert: ' text'}])

ShareDB implements OT types (e.g., json0, rich-text) and stores ops in an oplog for replay and persistence. (share.github.io)

Important: Both families support optimistic local edits and immediate local feedback. The difference is where the conflict-resolution logic lives: the transport/transform layer (OT) or the data type itself (CRDT).

Trade-offs: Complexity, performance, storage, and latency

Here’s a compact comparison you’ll use in architecture decisions.

Contrarian, practical insight from production experience: CRDTs are often marketed as the “easier” option because they sidestep transform algebra; in practice, robust CRDT-based systems require low-level systems engineering (compact binary formats, GC, snapshotting, and careful streaming protocols). Real-world benchmarking and engineering work drove Yjs (and similar projects) to highly optimized designs — not because CRDT theory was trivial, but because implementation and performance are hard. (josephg.com) (yjs.dev)

Latency and UX

Both models support instant local updates (optimistic UI). Perceived latency comes down to transport and how you show remote edits (cursor smoothing, incoming-change animation). OT often uses a server to serialize and transform which simplifies some UX decisions; CRDTs often show remote edits as they arrive and rely on convergence guarantees to resolve order differences. (share.github.io) (docs.yjs.dev)

Use cases: Which algorithm fits which problem

Pick with constraints in mind; here are practical rules of thumb that I’ve applied in production.

• Pick CRDT when:

  • Offline-first behavior is a hard requirement (mobile-first apps, intermittent connectivity). CRDTs merge naturally and don't require immediate server acknowledgement. (pages.lip6.fr)
  • You need peer-to-peer sync or want to avoid a single sequencer in the critical path. (yjs.dev)
  • Your application tolerates some extra storage or you can invest in compaction/GC infrastructure (or use an optimized CRDT like Yjs). (docs.yjs.dev) (josephg.com)

• Pick OT when:

  • Your product already centralizes edits for business reasons (real-time collaborative docs with server-side policies, fine-grained access control, audit logs) and you prefer controlling order at the server. (share.github.io)
  • You need minimal client metadata and tighter control of storage on the client (thin clients). (share.github.io)
  • You are integrating with mature OT-based stacks (existing ShareDB/Quill/Firepad ecosystem) and want to leverage proven tooling. (share.github.io)

• Edge cases / hybrid moments:

  • For rich structured editors (nested nodes, schema constraints) you’ll often reach for CRDTs that have editor bindings (e.g., y-prosemirror) or an OT type designed for your editor (e.g., rich-text delta with ShareDB). Yjs provides first-class ProseMirror bindings to keep schemas consistent while providing CRDT benefits. (github.com)

Implementation considerations and popular libraries

Your architecture will need several layers: the collaboration engine (OT or CRDT), the transport (WebSocket / WebRTC / WebTransport), the awareness/presence layer (cursors, user meta), and persistence/compaction. Here are the well-trodden picks and the trade-offs I run through immediately.

• Yjs (CRDT) — high-performance CRDT, editor bindings for ProseMirror/TipTap/Remirror, binary updates, GC/compaction primitives, many transports/providers. Good for local-first and peer-to-peer topologies. (yjs.dev) (docs.yjs.dev)
• Automerge (CRDT) — JSON-like CRDT with a focus on ergonomics; historically heavier on memory but has seen architectural improvements and Rust/WASM implementations. Best for apps where JSON-first modeling matters and peer-to-peer is desirable. (automerge.org)
• ShareDB (OT) — battle-tested Node.js OT backend; integrates with rich-text (Quill Delta) and json0. Good when you control the server and want a straightforward op-log storage model. (share.github.io)
• ot.js / Firepad — educational and earlier production stacks based on OT; useful if you want a tight OT integration with contenteditable or CodeMirror/ACE. (ot.js.org)
• Fluid Framework — Microsoft’s approach: not strictly OT/CRDT; it uses a total-order broadcast and DDS primitives optimized for Microsoft 365 scenarios. Good to study as an architectural alternative (hybrid sequencing + rich DDS semantics). (fluidframework.com)

Operational details you must plan for:

• Undo/Redo semantics: CRDTs provide local-scoped undo managers (Yjs exposes Y.UndoManager), but semantics differ from traditional global undo stacks. OT systems typically implement undo as inverse-ops or custom transform logic. (docs.yjs.dev) (share.github.io)
• Persistence & compaction: CRDTs need snapshot + compaction strategies; OT needs op-log trimming and snapshotting. Both need a robust plan for versioning and rollbacks. (docs.yjs.dev) (share.github.io)
• Connectivity & reconnection: Simulate high-latency, partitioned networks in tests. Test reconnect flows: in OT, you must replay/transform pending ops; in CRDT, you must be able to accept binary deltas and reconcile. (ot.js.org) (docs.yjs.dev)
• Measurements: track memory per-document, ops/sec, size of serialized updates, and GC latency. Benchmarks (open-source CRDT benchmarks and community write-ups) will help set expectations. (josephg.com)

Migration paths and hybrid approaches

Large products rarely rewrite collaboration layers overnight. Here are practical, low-risk paths I’ve used.

1. Dual-write shadowing (coexistence):

   • Run OT and CRDT for the same user flows in parallel (write both systems in production traffic but only read from the old system). Validate invariants and divergence with automated checks. This is heavy but the safest route for mission-critical docs.

2. Snapshot + replay migration (server-driven):

   • Export authoritative state (server snapshot or op-log).
   • Construct a fresh CRDT document and applyUpdate/apply historical ops as updates rather than replaying transforms; verify checksums. Yjs exposes binary update functions for this purpose. (docs.yjs.dev)

3. Incremental roll-forward (feature-flagged):

   • Start routing a subset of new documents to the new engine and monitor. Use read-after-write checksums and telemetry to validate correctness before broader roll-out.

4. Hybrid architecture (best of both worlds):

   • Use OT for server-authoritative sequencing where strict ordering or server-enforced invariants are required (e.g., transactional edits, permissions), and CRDTs for client-side offline merges or presence data. Microsoft’s Fluid shows an alternative path by using a total-order broadcast service to provide deterministic sequencing while exposing DDS primitives — it’s neither pure OT nor pure CRDT but a pragmatic hybrid. (fluidframework.com)

Practical snippet — export a Yjs binary snapshot and apply on another node:

// Export
const snapshot = Y.encodeStateAsUpdate(ydoc) // binary

// Import on target
const target = new Y.Doc()
Y.applyUpdate(target, snapshot)

This is the core mechanism for snapshot-and-restore or for bootstrapping new replicas. (docs.yjs.dev)

Practical Application

A concise working checklist and protocol to choose and implement a collaboration stack.

1. Requirements triage (constrained decision):

   • Offline requirement? Write that down and treat it as boolean.
   • Server-authoritative policies or audit trails? If yes, prefer server-aware OT or a hybrid.
   • Editor type? Plain text, rich text, structured JSON — map to available types (rich-text, ProseMirror, JSON CRDT). (share.github.io) (github.com)

2. Select engine & library:

   • Prioritize libraries that solve your data model and have production bindings: Yjs for ProseMirror/TipTap, ShareDB for Quill/Delta, Automerge for JSON-first local-first apps. (yjs.dev) (share.github.io) (automerge.org)

3. Design network protocol:

   • Choose between WebSocket for client-server and WebRTC for p2p. Use providers/adapters already supported by your library (Yjs has y-websocket, y-webrtc, etc.). (docs.yjs.dev)

4. Implement local optimistic update path:

   • Local change -> apply to local Doc/model -> render immediately -> broadcast change in background.

5. Persistence & GC policy:

   • For CRDT: implement compaction, snapshotting, and policies to purge tombstones or summarize history. For OT: define op-log retention and snapshot frequency. (docs.yjs.dev) (share.github.io)

6. Awareness & presence:

   • Implement a small, frequently-updated presence channel separate from document updates. Yjs has an Awareness protocol; ShareDB offers presence patterns. (docs.yjs.dev) (share.github.io)

7. Testing matrix:

   • Concurrency tests (N clients, M concurrent edits).
   • Partition tests: edits during a simulated network split and reconciliation afterwards.
   • Performance tests: large documents, high-frequency edits, paste events, mass undo/redo.

8. Telemetry & guardrails:

   • Track ops/sec, bytes transferred per sync, time-to-convergence, GC runtime, memory per document.
   • Add circuit breakers for unusually large updates or retention anomalies. (josephg.com)

9. Rollout strategy:

   • Pilot on low-risk documents, monitor, then expand with feature flags or tenant gating.

Quick protocol example (OT -> CRDT migration runbook):

1. Instrument checksums for every op/snapshot in the OT server.
2. For each doc to migrate, snapshot the document and op-log range.
3. Create a CRDT doc; apply the snapshot and then reapply ops as idempotent updates.
4. Run diff checks and hold in read-only mode until integrity checks pass.

Sources

A comprehensive study of Convergent and Commutative Replicated Data Types (Shapiro et al., 2011) - Formal definition and taxonomy of CRDTs; basis for state-based vs operation-based CRDT reasoning. (pages.lip6.fr)

Operational Transformation in Real-Time Group Editors (Sun & Ellis, 1998) - Canonical OT paper describing transform-based convergence and early correctness issues. (interaction-design.org)

Yjs — Homepage - Project overview, claims, and ecosystem; useful for understanding Yjs goals and supported bindings. (yjs.dev)

Yjs Documentation - API (Y.Doc, Y.Text), binary update format, editor bindings, GC/compaction notes and persistence strategy. (docs.yjs.dev)

Automerge (official) - Automerge project goals, JSON-like CRDT semantics, and cross-platform bindings. (automerge.org)

ShareDB Documentation (OT) - ShareDB architecture, OT types (json0, rich-text), persistence adapters and pub/sub for horizontal scaling. (share.github.io)

CRDTs go brrr — Joseph Gentle (engineering blog) - Practical benchmarking and engineering lessons comparing Yjs/Automerge performance and memory behavior (real-world perspective). (josephg.com)

y-prosemirror (Yjs binding for ProseMirror) - Implementation and examples showing how Yjs integrates with ProseMirror for rich structured editing. (github.com)

Fluid Framework FAQ (Microsoft) - Describes Fluid’s approach (total order broadcast and DDSes), and clarifies that Fluid is not a pure OT or CRDT implementation. (fluidframework.com)

OT.js — Operational Transformation docs - Practical explanation and historical context for OT, including examples and links to implementations. (ot.js.org)

Apply the checklist, measure early, and let operational constraints — not theory preferences — decide whether OT or CRDT will fit your editor’s product requirements.