Design Google Docs (Collaborative Editing)

Google Docs is a real-time collaborative document editor enabling concurrent, low-latency document modification.

1. High-Level Design

The fundamental challenge in collaborative editing is conflict resolution. When User A and User B type concurrently, their document offsets shift, leading to inconsistent text states if left unmanaged.

User A: Types "X" at pos 5  ----->  Doc Server (OT Resolution)  <-----  User B: Types "Y" at pos 5
       (Offset updated)                 (Synchronizes indices)                  (Offset updated)

Components

1. WebSocket Gateway: Maintains persistent bi-directional connections to client apps to stream edits with minimal latency.

2. Document Server (OT Engine): Houses in-memory Operational Transformation (OT) or CRDT matching logic. If User A and User B send edits concurrently at the same cursor offset, the server transforms the index positions chronologically.

3. Session Store: Keeps active document cursor states in Redis.

4. Storage Engine: Periodically flushes document snapshots to MongoDB/PostgreSQL, and appends delta edits to a Kafka commit log.

2. Potential Deep Dives

• Operational Transformation (OT) vs CRDTs:
• OT: The central server transforms edit commands before broadcasting them to other clients. Used by Google Docs due to simple client architecture.
• CRDT: Data structures (like LWW-Element-Set) resolve conflicts mathematically without requiring a central coordinator, but incur higher memory usage.
• Offline Editing:

Client app caches edits in IndexedDB. Upon reconnect, the client replays operations which are merged using OT/CRDT reconciliations.

3. References & Tech Blogs

• Google Engineering: Collaborative Editing Technology behind Docs
• Figma Engineering: Real-Time Collaboration using CRDTs