Design Google Docs: System Design Interview Guide

“Design Google Docs” is one of the most respected system design prompts because it’s fundamentally different from most CRUD-heavy questions (URL shorteners, rate limiters, feed systems). The hard part isn’t storage or scale in the traditional sense — it’s how multiple people can type into the same document simultaneously and end up with a consistent, correct result. This guide walks through how to structure a strong answer.

Why This Question Is Different

Most system design questions are about scaling reads and writes to a data store. Google Docs is about resolving concurrent edits to the same piece of data in real time, while keeping the user experience feeling instantaneous (no visible lag when you type) even though changes are being merged with other users’ changes happening at the same moment, potentially from the other side of the world.

Step 1: Clarify Requirements

Ask about:

• Concurrency level. Are we designing for 2-3 simultaneous editors (typical) or hundreds (rare, but changes the architecture significantly)?
• Latency expectations. Local typing must feel instant (no round-trip to a server before characters appear) — this rules out any design that blocks on network round-trips for every keystroke.
• Offline support. Should a user be able to keep editing while disconnected and merge changes when reconnecting?
• History/undo requirements. Full version history, like Google Docs’ revision history, adds real design constraints (you need an ordered, replayable log of changes, not just current state).

Step 2: The Core Problem — Concurrent Edits

Imagine two users, Alice and Bob, both start with the text “Hello”. Alice inserts “X” at position 0 (“XHello”), while at the same instant Bob inserts “Y” at position 5 (“HelloY”). If these operations are applied naively in different orders on different clients, the two clients can end up with different final documents — a correctness bug, not a race that just “usually” doesn’t matter.

The two mainstream solutions to this are Operational Transformation (OT) and CRDTs (Conflict-free Replicated Data Types). A strong interview answer names both, explains the trade-off, and picks one to go deep on.

Operational Transformation (OT)

OT represents edits as operations (insert(pos, char), delete(pos, len)) and transforms incoming operations against concurrently applied ones so they can be applied in a consistent order regardless of arrival sequence. In the example above, when Bob’s insert arrives at Alice’s client after her own insert has already shifted the document, OT transforms Bob’s operation’s position index to account for Alice’s shift, so it still lands in the intended logical location.

OT requires a central server to serialize operations (assign them a canonical order) in most practical implementations, which simplifies conflict resolution but means the server is a critical, stateful component in the edit path. Google Docs’ original implementation (Google Wave heritage) is OT-based.

CRDTs (Conflict-Free Replicated Data Types)

CRDTs take a different approach: instead of transforming operations relative to each other, they design the data structure itself so that any two replicas, having received any set of operations in any order, mathematically converge to the same state without needing a coordinating server. A common technique for text is representing each character with a unique, globally ordered identifier (rather than a raw array position), so inserts and deletes commute regardless of arrival order.

CRDTs are more naturally decentralized (no single server required to serialize operations) and handle offline editing and merge-on-reconnect more gracefully, which is why many newer collaborative editors (including some modern rewrites of Google-Docs-style products) lean CRDT. The trade-off is higher memory overhead (each character needs metadata, not just its value) and the algorithms are generally more complex to implement correctly than OT’s server-mediated model.

Comparison Table

Step 3: Real-Time Sync Architecture

Regardless of OT vs CRDT, the surrounding architecture looks similar:

1. Client-side buffer. Local edits apply immediately to the user’s own view (optimistic UI) so typing never waits on the network.
2. WebSocket connection to a document server maintains a persistent, low-latency channel for both sending local operations and receiving remote ones.
3. Document server (for OT) assigns a sequence number to each incoming operation, transforms it against any operations that happened concurrently, and broadcasts the transformed operation to all other connected clients.
4. Persistence layer periodically snapshots document state (so you don’t need to replay the entire operation history from the beginning of time to reconstruct current state) and stores the operation log for revision history.

Step 4: Conflict Resolution in Practice

Even with OT or CRDTs handling character-level merges correctly, product-level conflict resolution decisions still need explicit design:

• Same-position deletes. If two users delete overlapping text ranges simultaneously, the algorithm needs a deterministic tie-break rule (e.g., by user ID or operation timestamp) so all clients converge on the same result.
• Formatting conflicts. Rich text (bold, font size, comments) adds another dimension beyond plain character insertion/deletion — most production designs model formatting as a parallel CRDT/OT stream layered on top of the character stream.

Step 5: Cursor Synchronization

Seeing other users’ live cursors and selections is a core part of the collaborative experience, but it’s a fundamentally different, simpler problem than text merging: cursor position doesn’t need conflict resolution, since each user’s cursor is independently owned. The typical design:

1. Each client periodically broadcasts its own cursor position (as a stable position reference, not a raw character index, so it stays correct as the document changes underneath it) over the same WebSocket channel used for edits.
2. Other clients render a labeled cursor/selection overlay for each remote user, keyed by user ID and color.
3. Because cursor updates are frequent and don’t need durability, they’re often sent over a lighter-weight or even best-effort channel (not persisted to the operation log), since losing a stale cursor position update is harmless.

Failure Modes to Call Out

• Server becomes a bottleneck under OT. Since the central server serializes every operation for a document, a single very popular shared document (unusual but possible) could bottleneck on a single server instance; sharding by document ID is the standard mitigation.
• Reconnection after network drop. The client needs to replay any locally-buffered edits made while offline, and the server/CRDT merge logic needs to correctly integrate them without data loss or duplication.
• Operation log growth. Without periodic snapshotting, replaying a long-lived document’s full operation history to reconstruct state becomes slow; snapshot-plus-recent-ops is the standard mitigation, similar to event sourcing snapshotting patterns elsewhere in system design.

Sample Interview Answer Structure

1. Clarify concurrency scale, offline requirements, and history needs — 2 minutes.
2. Introduce the core concurrent-edit problem with a concrete example — 2 minutes.
3. Present OT and CRDTs, pick one, justify the choice — 4 minutes.
4. Describe the WebSocket-based real-time sync architecture — 3 minutes.
5. Cover conflict resolution edge cases (overlapping deletes, formatting) — 2 minutes.
6. Describe cursor sync as a separate, lighter-weight concern — 2 minutes.

Practice More

The 0-to-1 SWE Interview Playbook (Amazon: https://www.amazon.com/dp/B0H256Z1MF?tag=sirjohnnymai-20) covers real-time collaborative system design alongside dozens of other high-signal prompts, with the same interviewer-perspective structure used in this guide.

Key Takeaways

• The core challenge is concurrent edit resolution, not storage scale — name OT and CRDTs and justify your pick.
• OT centralizes ordering on a server; CRDTs push convergence into the data structure itself and handle offline/peer-to-peer scenarios more naturally.
• A WebSocket-based sync architecture with periodic snapshotting is the standard real-time backbone regardless of merge algorithm.
• Cursor synchronization is a separate, much simpler problem than text merging — don’t conflate the two in your answer.