🎯 How Notion Handles Collaborative Editing
1️⃣ Core Collaboration Framework (Staff-Level)
When discussing a Notion-like collaborative editor, I frame it as:
- Local-first editing
- Operation log
- Conflict resolution
- Server sequencing
- Presence and cursors
- Snapshots and compaction
- Offline and reconnect recovery
- Trade-offs: responsiveness vs convergence vs complexity
2️⃣ Core Problem
Multiple users can edit the same document at the same time.
The system must provide:
- instant local typing
- eventual convergence
- multi-device sync
- offline tolerance
- conflict handling
- document history
- efficient loading for large documents
👉 Interview Answer
A Notion-like editor should feel local but converge globally. The client applies edits immediately, sends operations to the server, and the system merges concurrent operations into a shared document state.
3️⃣ High-Level Architecture
Client Local Editor
↓
Operation Builder
↓
Sync Service
↓
Document Operation Log
↓
Conflict Resolver / Sequencer
↓
Snapshot Store
↓
Broadcast to Collaborators
4️⃣ Operation-Based Sync
Instead of sending the whole document, clients send operations:
insert block
delete block
update text
move block
change property
Each operation includes:
- document ID
- base version
- operation ID
- client ID
- timestamp
- payload
👉 Interview Answer
Operation sync is better than repeatedly sending full documents. It reduces bandwidth, enables history, and gives the system a way to merge concurrent edits.
5️⃣ Conflict Resolution
Common approaches:
- OT: Operational Transformation
- CRDT: Conflict-free Replicated Data Types
- server-authoritative sequencing with merge rules
For block-based documents, conflicts often involve:
- two users editing same text
- one user deletes a block while another edits it
- concurrent block moves
- offline edits replayed later
👉 Interview Answer
The exact algorithm can be OT, CRDT, or a server-sequenced operation model. The important interview point is that concurrent operations must be transformed or merged so all clients converge to the same document state.
6️⃣ Snapshots and Compaction
Operation logs grow forever if not compacted.
Use:
- periodic document snapshots
- operation log after latest snapshot
- compaction of old operations
- version checkpoints
Load path:
Load latest snapshot
↓
Replay recent operations
↓
Return current document
7️⃣ Presence
Presence includes:
- online users
- cursor position
- selected block
- typing indicator
Presence is ephemeral and should not be stored like durable document edits.
8️⃣ Offline and Reconnect
Client behavior:
- buffer local operations
- assign stable operation IDs
- replay on reconnect
- handle server-accepted order
- resolve rejected or transformed operations
9️⃣ Staff-Level Trade-offs
| Decision | Benefit | Cost |
|---|---|---|
| Local-first editing | Great UX | More sync complexity |
| Operation log | History and mergeability | Needs compaction |
| CRDT-style merge | Offline-friendly | Higher metadata overhead |
| Server sequencing | Easier authority | More dependence on server |
| Presence over sockets | Realtime collaboration | Ephemeral scaling cost |
中文部分
中文速记
一句话
Notion Collaborative Editing 的核心是 local-first editing + operation sync：本地先响应，后台同步并保证最终收敛。
背诵要点
- 不要每次传整个 document，要传 operation
- operation log 支持历史、同步和冲突处理
- 并发编辑要靠 OT、CRDT 或 server sequencing 合并
- 大文档要用 snapshot + recent operations 加速加载
- presence/cursor 是临时状态，不要和 durable edits 混在一起
中文面试回答
我会把 Notion 协作编辑设计成 local-first 的 operation-based sync。 用户输入时，客户端先在本地立即应用编辑，保证打字体验低延迟。 同时客户端生成 operation，比如 insert block、delete block、update text、move block，并带上 document ID、base version、operation ID 和 client ID 发给 sync service。
服务端负责给 operation 排序或做 merge，然后写入 document operation log，并广播给其他协作者。 对于并发编辑，可以使用 OT、CRDT 或 server-authoritative sequencing，关键是所有客户端最终要收敛到同一个文档状态。
Staff 级重点是：协作编辑的难点不是保存文档，而是在低延迟体验和一致收敛之间做平衡。 大文档还需要 snapshot 和 compaction，避免每次加载都 replay 全部历史操作。
✅ Final Interview Answer
A Notion-like collaborative editor uses local-first editing with operation-based synchronization. The client applies edits immediately, creates operations with base versions and operation IDs, and sends them to a sync service. The server sequences or merges operations, persists them in a document operation log, and broadcasts accepted changes to other clients.
To keep large documents efficient, the system periodically creates snapshots and only replays recent operations. Presence and cursors are handled separately as ephemeral realtime state. At staff level, the core trade-off is responsiveness versus convergence complexity: users want instant editing, but the system must still guarantee that all clients eventually see the same document.
Implement