Design Google Docs — Real-Time Collaborative Editing

Problem Statement

Design a real-time collaborative document editor like Google Docs. Multiple users should be able to edit the same document simultaneously and see each other's changes in near real-time, with no conflicts or lost updates.

Requirements

Functional:

• Multiple users edit the same document concurrently
• Changes propagate to all users in real-time
• Cursor positions and selections are shared
• Edits never conflict or get lost
• Offline edits sync when reconnected

Non-Functional:

• Low latency (< 100ms for edit propagation)
• Consistency — all users converge to the same document state
• Scale to millions of documents

What the Interviewer Expects

1. Real-time transport — WebSockets for bidirectional low-latency communication (vs polling).

2. The core problem: conflict resolution. Two main approaches:

   • Operational Transformation (OT): transform concurrent operations against each other so they can apply in any order and converge. What Google Docs actually uses. Complex to implement correctly.
   • CRDT (Conflict-free Replicated Data Types): data structures that mathematically guarantee convergence without a central transform. Simpler reasoning, more memory overhead.

3. OT vs CRDT — when to use which:

   • OT: central server, lower memory, battle-tested but complex transform functions
   • CRDT: peer-to-peer friendly, eventual consistency, higher metadata overhead

4. Document data structure — how to represent the document for efficient edits (piece tables, ropes, or sequence CRDTs) rather than a plain string.

5. Architecture — client → WebSocket gateway → document service (holds authoritative state) → persistence. Presence service for cursors.

Follow-ups

1. How do you handle a user editing offline for hours and then reconnecting?
2. What data structure would you use to store the document for efficient insert/delete at any position?
3. How do you handle cursor/selection sharing as text shifts around?
4. How do you scale a single very popular document with thousands of concurrent editors?
5. How would you implement version history and the ability to revert?