Intro
A collaborative editor must make concurrent edits converge without losing user intent. WebSockets reduce delivery latency, but convergence comes from the operation model. Store document operations durably, identify their causal base, and make retries idempotent.
OT and CRDT Choose Different Costs
| Question | Centralized operational transformation | Sequence CRDT |
|---|---|---|
| Ordering | Server establishes a revision order and transforms stale operations | Operations carry identities or positions that merge under the CRDT rules |
| Offline work | Requires rebasing queued operations when reconnecting | Can merge independently created operations when causal metadata is retained |
| Metadata | Transformation history or sufficient revisions | Per-element identifiers, tombstones, or compaction metadata |
| Main risk | Incorrect transform functions break convergence or intent | Metadata growth and complex garbage collection |
Use centralized OT when one online service owns ordering and the editing primitives are bounded. Use a CRDT when offline or peer-to-peer editing is a real requirement and the product can pay the metadata and compaction cost. Neither label removes the need for permissions, snapshots, or durability.
Operation Log and Snapshot
Suppose revision 20 contains cat. Alice inserts s at position 0 while Bob deletes t, both based on revision 20. The server must not apply two raw integer offsets blindly. It transforms the second operation against the accepted first operation, or resolves both through the CRDT’s stable element identities, then broadcasts the canonical operations.
Each submission carries document_id, actor_id, operation_id, causal base, and payload. A unique (document_id, operation_id) fence makes reconnect retries safe. Periodic snapshots bound replay time, but retain the operation range needed by clients whose last acknowledged revision predates the snapshot.
Transport and storage do not guarantee convergence; the chosen OT or CRDT algorithm defines how concurrent operations combine.
Presence, cursor position, and selection are ephemeral collaboration signals. Keep them outside the durable document history and enforce document authorization again when a client reconnects.
References
- Jupiter collaboration system paper — primary operational-transformation design for low-bandwidth, high-latency collaborative editing.
- A comprehensive study of CRDTs — primary CRDT model, convergence properties, and operation/state-based designs.
- RFC 6455: The WebSocket Protocol — transport framing and connection behavior used by interactive synchronization channels.
- ByteByteGo: design Google Docs — provenance for the client, WebSocket, queue, operation-service, cache, and storage topology.