Design a Collaborative Editor (Google Docs)
Interview Prep mode active
Interview answer templates and key talking points. Switch the mode in the header to change your experience.
Step 1 — Constraints
100 concurrent users editing the same document. Less than 100ms latency. Conflict resolution required. Undo/redo?
Step 2 — Decision: Operational Transformation vs CRDT
| Approach | Complexity | Consistency | Offline |
|---|---|---|---|
| OT (Operational Transformation) | High | Strong | Medium |
| CRDT (Conflict-free Replicated Data Type) | Very high | Eventual | Excellent |
Winner: OT. Simpler for 100 concurrent users.
Step 3 — OT concept
Each edit is an operation. Server transforms concurrent operations to resolve conflicts while maintaining consistency.
Maintain a version vector for causality tracking.
Step 4 — Undo/redo in collaborative context
Undo stack stores all operations. Undo = apply the inverse operation.
Challenge: If you undo while someone else is typing, their changes can get affected.
Solution: Store original intent. Undo applies to that intent, not the result.
Step 5 — Gotchas
N^2 complexity with OT at high concurrency.
Cursor position tracking gets complicated with concurrent edits.
Undo in collab context is unintuitive.
Step 6 — Anti-patterns
Junior: Mutual exclusion locks (one user at a time). Result: Slow, defeats collab.
Mid: Perfect consistency without considering offline. Result: Can't work offline.
Senior: Optimize OT algorithm before proving it's a bottleneck. Result: Premature.
Step 7 — 30-minute interview
0–5 min: "100 concurrent? Less than 100ms? Offline support?"
5–15 min: Sketch OT approach. Version vector. Undo stack.
15–30 min: "How do you handle conflicts? Offline edits? Cursor sync?"
Step 8 — Interview simulation
Interviewer: "Design collaborative editor for 100 concurrent"
You: "Operational Transformation: each edit is an operation. Server transforms concurrent ops to maintain consistency. Version vector for causal ordering. Undo stack stores operations; undo applies inverse."
Interviewer: "What if two users edit the same paragraph?"
You: "OT resolves it deterministically. Both clients see the merged result. If user A deletes text and user B inserts at same position, OT adjusts the insertion position."
Interviewer: "How do you handle offline edits?"
You: "Queue operations locally. When online, replay against current version. Resolve conflicts using OT."
Step 9 — Tiered answer
| Level | Time | What You Say |
|---|---|---|
| Junior (15 min) | Last-write-wins, store in DB | |
| Mid (25 min) | OT, version vector, operational transforms | |
| Senior (30 min) | OT + undo + offline + awareness (cursors) |
Step 10 — Final checklist
| Issue | Solution |
|---|---|
| Conflict resolution | Operational Transformation |
| Consistency | Version vector for causality |
| Undo/redo | Undo stack, apply inverse |
| Offline edits | Queue operations, replay on reconnect |
| Cursor tracking | Awareness channel with position deltas |
| Latency | Optimistic local ops, confirm from server |
| Persistence | Log all operations, replay to get state |
"Operational Transformation for 100 concurrent users. Each edit is an operation; server transforms concurrent operations to maintain consistency. Maintain version vector for causality. Undo stack stores operations; undo applies inverse. Offline edits queued and replayed on reconnect. Track user cursors and selections via awareness channel."