Design Google Doc

Functional

Two people type into the same paragraph at the same instant. One adds a sentence, the other deletes a word. The core challenge of Google Docs is not building a text editor; it is merging those concurrent edits without losing either person's work.

• Real-time collaborative editing: Multiple users edit the same document simultaneously. Each user sees every other user's changes within 100ms of the edit being made. Local edits apply instantly on the author's screen before the server confirms them.
• Offline editing with automatic sync: A user disconnects (airplane mode, poor Wi-Fi), continues editing, and reconnects later. All offline edits merge automatically with changes made by other users during the disconnection. No manual conflict resolution required.
• Comments and suggestions anchored to text ranges: Users attach comments to specific words or paragraphs. Suggestions propose inline edits that the document owner can accept or reject. Anchors remain stable as surrounding text changes.
• Sharing and permissions: Document owner controls access at four levels: owner (full control including delete), editor (modify content), commenter (add comments only), and viewer (read-only). Link sharing enables public or organization-wide access at any permission level.
• Revision history with restore: The system records every change with timestamp and author. Users browse past versions, compare differences, and restore any previous version. Restoring creates a new version rather than erasing history.
• Rich text formatting: Users apply bold, italic, underline, headings, bullet lists, and numbered lists. Formatting operations are concurrent with text edits; one user can bold a word while another inserts text nearby. The system must merge formatting changes with the same consistency guarantees as text edits.

Users and Sessions

The numbers below drive every architectural choice. Pay attention to ops/sec, it tells us why we need a specialized conflict-resolution algorithm instead of database locks.

• Registered users: 10M total.
• Concurrent connections: 1M (10% of registered users online simultaneously).
• Concurrent editors: 200K actively typing. The remaining 800K are passive viewers or idle.
• Average document: 2-3 simultaneous editors. Hot documents (company announcements, shared meeting notes) can have up to 100 simultaneous editors. The vast majority of documents (95%+) have 1-5 editors, so the system is optimized for the common case but must handle the hot document scenario without degradation.

REST (Control Plane)

The API splits into two channels: REST for infrequent control actions and WebSocket for the continuous stream of edits. Sending an HTTP request per keystroke would add 50-100ms of overhead per edit, unacceptable for real-time typing.

• POST /documents: Create a new document. Body includes title and optional template_id. Returns document_id and WebSocket URL for immediate editing.
• GET /documents/:doc_id: Fetch document metadata (title, owner, permissions, last modified, current version number, active editor count).
• POST /documents/:doc_id/comments: Add a comment anchored to a text range. Body includes anchor_start (character ID or position), anchor_end, comment text, and optional parent_comment_id for threaded replies. Returns comment_id.
• POST /documents/:doc_id/share: Update sharing permissions. Body includes user_email and role (editor, commenter, viewer). The server sends a notification to the invited user and immediately updates the permission cache on all collaboration servers holding this document.
• GET /documents/:doc_id/revisions: List revision history with timestamps, authors, and summary of changes. Paginated with cursor-based pagination (cursor is a revision number, not an offset).
• POST /documents/:doc_id/revisions/:rev_id/restore: Restore document to a previous revision. Creates a new revision (new version number) with the old content rather than rolling back. This preserves the complete history and allows other editors to merge their subsequent changes.

Operation Log

The database follows an event-sourcing pattern. Instead of storing the latest text and overwriting on every keystroke, we store the stream of operations that produced it. This gives us revision history, offline merge capability, and crash recovery for free.

Event sourcing inverts the typical database model. In a traditional approach, the document text is the primary data and history is a derived feature. In event sourcing, the operation log is the primary data and the current document text is derived by replaying operations. This inversion makes every feature that depends on history (versioning, undo, merge) a natural consequence of the storage model rather than an afterthought.

The architecture has four layers, each with a distinct responsibility. The client holds a local copy and applies edits instantly. The collaboration server merges operations from all connected clients. A PubSub bus synchronizes servers across regions. The storage layer persists the op log and snapshots.

Client Layer

Two flows define this system: real-time concurrent editing (Alice and Bob typing simultaneously) and offline sync (Carol reconnects after hours offline). Both use the same merge algorithm, the offline case is simply a delayed version of the real-time case. Understanding both flows is essential because they demonstrate that the architecture handles the full spectrum of connectivity, from perfect real-time to extended disconnection.

Real-Time Concurrent Editing

The question "how do you merge concurrent edits?" is the question an interviewer is really asking when they say "design Google Docs." The conflict-resolution algorithm is what makes this problem unique. Everything else (APIs, databases, load balancers) is standard infrastructure that appears in many system design problems. This section is the GATE.

Two algorithms dominate: Operational Transformation (OT) and Conflict-free Replicated Data Types (CRDT). Both guarantee convergence, every replica reaches the same state. They differ in how they achieve it. Understanding both, including their trade-offs, is what separates a strong answer from a surface-level one.

Operational Transformation (OT)

Three decisions cascade through the entire design: which merge algorithm, what consistency model, and whether to batch writes. Each choice has clear costs and benefits. In an interview, explicitly state the trade-off for each decision, do not just name the choice, explain what you gain and what you pay.

OT vs CRDT

A collaboration server crashes mid-edit. A network partition splits editors across continents. A viral document attracts 100 simultaneous editors. Each failure traces back to a core design choice, and in an interview, connecting the failure to the design decision demonstrates deep understanding.

Server Crash

The collaboration server holding a document's state crashes. All connected editors lose their WebSocket connection.

Four extensions beyond the core design: richer content types, real-time presence visualization, cross-region optimization, and smarter conflict handling. Each builds on the CRDT foundation without requiring fundamental architectural changes.

Rich Text CRDT

The current design operates at the character level (plain text only. Rich text adds formatting ranges) bold characters 5-10, italic characters 12-15. When a user inserts a character at position 7, the bold range must expand to include it. When another user inserts at position 12, the system must decide whether the new character inherits italic formatting. This boundary problem is one of the hardest aspects of rich text CRDT.