Building Real-Time Collaboration: CRDTs, WebSockets, and Operational Transform

Introduction

Real-time collaboration has become a baseline expectation. Users expect Google Docs-like co-editing in every application. But the engineering behind seamless real-time collaboration is deep — involving distributed systems theory, conflict resolution algorithms, and careful network architecture.

This post covers the three main approaches to real-time collaboration, their trade-offs, and how to build a production-ready system.

WebSocket Fundamentals

WebSockets provide the transport layer for real-time collaboration:

• Persistent connections: Unlike HTTP, WebSockets maintain an open connection for bidirectional communication
• Low latency: Messages are delivered in milliseconds, enabling real-time cursor tracking and typing indicators
• Server-side fan-out: When one user makes a change, the server broadcasts it to all other connected users
• Reconnection handling: Production systems must handle disconnects gracefully — buffer operations and replay on reconnect

For production, we recommend Socket.IO or native WebSocket with a custom reconnection layer. At scale, use a Redis-backed pub/sub for cross-server message distribution.

Operational Transform

Operational Transform (OT) is the algorithm behind Google Docs:

• Core idea: Transform concurrent operations so they can be applied in any order and produce the same result
• How it works: When two users type at the same position, the server transforms one operation's position based on the other
• Pros: Well-understood, battle-tested at Google-scale, excellent for text editing
• Cons: Complex to implement correctly (the algorithm has subtle edge cases), requires a central server for transformation

OT works well for text documents but becomes increasingly complex for rich data structures like spreadsheets, diagrams, or hierarchical documents.

CRDTs Explained

Conflict-free Replicated Data Types (CRDTs) are the modern alternative:

• Core idea: Design data structures that can be merged automatically without conflicts, regardless of operation order
• Types: G-Counter, PN-Counter, LWW-Register, OR-Set, and tree-based CRDTs for text (Yjs, Automerge)
• Pros: No central server needed (peer-to-peer capable), mathematically guaranteed convergence, works offline
• Cons: Higher memory overhead (tombstones for deletions), more complex initial implementation

Libraries like Yjs and Automerge have made CRDTs practical for production use. Yjs, in particular, powers collaborative features in applications serving millions of users.

Production Architecture

A production-ready real-time collaboration system:

• Client layer: CRDT library (Yjs) + WebSocket provider + awareness protocol (cursor position, user presence)
• Sync server: Handles WebSocket connections, broadcasts updates, and persists document state
• Persistence layer: Snapshots every N operations + operation log for replay
• Presence service: Tracks who's online, what they're viewing, and cursor positions
• Conflict resolution: CRDTs handle this automatically; OT requires a transform server

Scaling considerations:

• Use sticky sessions or a shared document state store for multi-server deployments
• Implement document-level sharding — each document lives on one server
• Rate-limit updates to prevent overwhelming slow clients

Choosing Your Approach

Use Operational Transform when:

• You're building a text-only editor
• You have a reliable central server
• You need minimal client-side memory overhead

Use CRDTs when:

• You need offline support
• Your data structures are complex (not just text)
• You want peer-to-peer capability
• You need guaranteed convergence without a central authority

Our recommendation: For most new projects, start with Yjs (a CRDT library). It has excellent TypeScript support, works with React, and integrates with popular editors (TipTap, ProseMirror, Monaco). The ecosystem has matured to the point where CRDTs are the pragmatic choice.