Questions › System Design

Design a real-time collaborative editor

Collaborative EditingHardSystem Design

Design a collaborative document editor (à la Google Docs). Apply RADIO; cover presence, conflict resolution, and offline.

What it tests

Concurrent-edit convergence (OT vs CRDT), presence/cursors, offline reconciliation, and latency compensation.

Approach & answer

Requirements: multiple users edit one document simultaneously, see each other's cursors/presence, converge to an identical state, and keep working offline. This is the hardest front-end consistency problem: concurrent edits must merge with no central lock. Architecture: each client holds a local replica and applies edits instantly (optimistic); edits are sent to a server that relays them to peers; a merge algorithm guarantees convergence. The core fork is CONFLICT RESOLUTION. OPERATIONAL TRANSFORMATION (OT) sends operations (insert@5, delete@3) and TRANSFORMS incoming ops against ones applied since, so concurrent inserts don't corrupt positions — powerful but the transform functions are notoriously hard to get right and usually need a central server to order ops. CRDTs (conflict-free replicated data types) give each character a unique, ordered id so operations are commutative and merge deterministically with no transform and no central authority — simpler correctness and true offline/peer-to-peer, at the cost of metadata overhead (tombstones for deletes). Modern editors lean CRDT (Yjs, Automerge). Presence: broadcast lightweight EPHEMERAL state (cursor position, selection, name/color) out-of-band from the document ops — it needn't persist. Hard parts: LATENCY COMPENSATION (apply locally first, reconcile remote ops as they arrive); OFFLINE (queue local ops, merge on reconnect — where CRDTs shine); intention preservation so a merge keeps what each user meant; and transport is usually WebSocket for low-latency bidirectional sync. Bound memory by garbage-collecting CRDT tombstones.

Use this technique when

Collaborative docs/whiteboards/design tools; explaining OT vs CRDT, presence, and offline merge.

Code

Client A ─ local replica (edit applied instantly, optimistic)
   │  ops
   ▼
Server ── orders / relays ops ──► broadcast to peers
   │
   ▼
Client B ─ merge incoming ops into local replica

Merge strategy:
  OT   — send operations, TRANSFORM against concurrent ops
         (needs a central server to order; transforms are hard)
  CRDT — unique ordered id per char -> ops commute, merge with no
         transform, works offline / p2p (cost: tombstone metadata)

Presence (cursor, selection, name) — ephemeral, sent out-of-band,
never persisted. Transport: WebSocket (low-latency, bidirectional).

References