Question 1

How does Operational Transformation (OT) resolve concurrent edits in collaborative editing?

Accepted Answer

OT represents edits as operations: Insert(position, text) and Delete(position, length). When two clients make concurrent edits, their operations must be transformed against each other to account for position shifts. Example: document 'hello'. Client A: Insert(5, ' world') — insert at position 5. Client B simultaneously: Delete(0, 1) — delete 'h' at position 0. If A's operation is applied first: 'hello world'. B's Delete(0,1) remains valid — deletes 'h' to get 'ello world'. If B applied first: 'ello'. A's Insert(5, ' world') must be transformed: B deleted 1 character before position 5, shifting the target left by 1 — transformed to Insert(4, ' world') → 'ello world'. Both orders converge to 'ello world'. The transformation function adjusts positions based on the length and position of concurrent operations. A central server orders all concurrent operations and broadcasts transformed versions to all clients, guaranteeing convergence. Google Docs uses OT.

Question 2

What are CRDTs and how do they differ from OT for collaborative editing?

Accepted Answer

CRDTs (Conflict-free Replicated Data Types) are data structures designed so concurrent updates always merge without conflicts — no transformation or central server required. For text: each character has a globally unique ID (site_id + logical_clock). Insert and delete operations reference character IDs, not positions. Since IDs are stable (unlike positions that shift as text changes), concurrent operations can be applied in any order and will converge to the same result. Delete operations use tombstoning — the character is marked deleted but retained in the data structure for ordering references. Concurrent inserts at the same position are ordered deterministically by site_id (a tiebreaker). Key differences vs. OT: (1) No central server needed — peers can sync directly. (2) Simpler client implementation — no transformation function. (3) Works offline naturally — accumulate operations, sync when reconnected. (4) Downside: tombstones accumulate over time (deleted characters stay in memory) — requires periodic compaction. Y.js and Automerge are popular CRDT libraries used by Notion and Figma.

Question 3

How does real-time sync work in a collaborative document editor?

Accepted Answer

Each editing client maintains a persistent WebSocket connection to a document server. Edit flow: (1) User types a character — the client generates an operation and applies it locally immediately (optimistic local apply, no server round-trip needed for the user to see their own change). (2) Client sends the operation to the server via WebSocket. (3) Server receives the operation. For OT: transforms it against any concurrent operations received since the client's last known state, then broadcasts the transformed operation to all other connected clients. For CRDT: broadcasts the raw operation directly (no transformation needed). (4) Other clients receive the broadcast, apply the operation to their local replica. The round-trip for other clients to see your change is typically 50-150ms (WebSocket latency). Presence features (cursor positions, selections of other users) are sent as separate lightweight events on the same WebSocket connection — cursor positions are not part of the document state and don't need the OT/CRDT merge logic.

Question 4

How do you persist document history and support version control in a collaborative editor?

Accepted Answer

Persistence strategy: append every operation to an immutable operation log — (op_id, doc_id, user_id, timestamp, operation_type, position, content). The current document state is the result of replaying all operations from the beginning. Snapshot + delta for performance: replaying 1M operations on every document open is too slow. Take periodic snapshots of the full document state (every 1000 operations or every hour): store as a blob in object storage (S3). On document open: load the latest snapshot and replay only the operations after it (typically a few hundred). Snapshot creation is async and doesn't block real-time editing. Version history (Google Docs 'named versions'): tag specific points in the operation log as named versions. To restore: replay operations up to the tagged operation. Version diffing: compare two snapshots by diffing their text content. Undo/redo: maintain an undo stack of operations per user — undo generates an inverse operation (Insert undoes Delete and vice versa). In collaborative editing, undo only undoes the local user's operations, not concurrent edits from others — OT-aware undo tracks which operations to reverse.

Collaborative Document Editing: Low-Level Design

Operational Transformation (OT)

CRDTs for Conflict-Free Merging

Real-Time Sync Architecture

Persistence and Version History

Access Control and Offline Editing