Design Google Docs

Design a collaborative document editor like Google Docs. Several people edit the same document at once and see each other's changes and cursors within a fraction of a second.

1. Clarify the requirements

Before drawing anything, ask questions. These are the answers an interviewer would typically give:

How many users?

50 million daily active users; about 10 million documents are edited each day.

How many people edit one document?

Usually 1 to 5 at a time, up to about 100 on a popular document.

How fast must changes appear?

Your own typing must feel instant; other people's edits should appear within about 300 ms.

Offline editing?

Short disconnections must not lose work. A full offline mode is out of scope.

Version history?

Yes: users can see and restore older versions.

Sharing?

Owner, editor, commenter and viewer roles; share with people or by link.

2. Estimate the scale

Assumptions: 50M DAU. 10M documents edited per day, average size 100 KB. At peak, 2M documents are open for editing with 1.5 editors each, and each active editor sends about 1 operation per second.

• Concurrent editing connections at peak: about 3.0M connections2M documents × 1.5 editors = 3M open connections.
• Edit operations per second at peak: about 3.0M ops/s3M editors × 1 op/s ≈ 3M ops/s, spread across many collaboration servers.
• Snapshot data written per day: about 1 TB10M edited documents × 100 KB ≈ 1 TB/day if each gets at least one snapshot.

3. The high-level design

1. Everyone on a document meets on one serverEditors connect over WebSockets, and sticky routing sends everyone editing the same document to the same collaboration server.
2. Live state in memoryThe open document and everyone's cursors live in memory for speed; the document store holds metadata and the latest snapshot.
3. Every edit goes to a durable logEach operation is appended to an ordered log, so a session can be rebuilt after a crash and history can be replayed.
4. Snapshots and version historyA snapshot service reads the log and, every few hundred operations, writes a compacted snapshot and a version-history entry to object storage.
5. Watch it in productionMetrics and alerts close the loop: edit round-trip latency, connections per server and log lag.

4. The components and what each one does

Load balancer Load balancer

Sticky routing: every editor of a document reaches the same collaboration server.

Collaboration servers App servers

One session per open document: orders concurrent edits with operational transformation (OT) and broadcasts them over WebSocket connections. Otherwise stateless: a session can restart on any server from the log, so the tier scales out horizontally.

Open documents Cache

Live document state and cursors per session.

Document store NoSQL / KV store

Metadata and latest snapshot pointer; sharded by document ID; replicas with failover.

Operation log Event stream · Kafka

Every edit, in order: a durable, replayable log.

Snapshot service Service

Consumes the operation log; writes compacted snapshots and version history. Scales out with the log partitions.

Metrics & alerts Metrics & alerts

Dashboards and alerts on p99 latency, error rate, queue depth and cache hit ratio, so a bottleneck shows up before it becomes an outage.

5. Deep dive: merging concurrent edits

Alice and Bob type into the same sentence at the same moment. How does every editor end up with exactly the same text? Compare operational transformation (OT) and CRDTs, and say where the order of operations is decided.

• Send small operations (insert 'x' at 42, delete 3 characters at 10), never whole documents.
• Operational transformation: one server orders each document's operations and transforms concurrent ones against each other so their positions still make sense.
• CRDTs give every character a unique, ordered ID so copies merge without a central server, at the cost of extra metadata.

6. What interviewers listen for

• A real-time channel that carries operationsEdits flow both ways continuously: a WebSocket per open document carries small operations.
• Data model: documents, operation log, snapshotsAn append-only operation log plus periodic snapshots can rebuild any version.
• OT or CRDT to merge concurrent editsWithout a merge algorithm, concurrent edits corrupt the text or overwrite each other.
• One owner orders each document's operationsRouting everyone editing a document to the same collaboration server (consistent hashing on the document ID) gives one place that decides the order.
• Periodic snapshots and log compactionReplaying millions of operations to open a document is slow; snapshot every N operations.
• Cursors and presenceCollaborators' cursors are short-lived: broadcast them, don't store them.
• Reconnect and resend unacknowledged editsClients keep unacknowledged operations locally and resend them after a reconnect.
• Permission check on every operationA viewer with an open socket must not be able to send edits.
• Database replication and failoverA single database is a single point of failure. Replicas give redundancy and read capacity; failover promotes a replica when the primary dies.
• Partition (shard) data as it growsOne machine eventually can't hold the data or the write load. Say how you'd split it and by which key.

7. Follow-up questions

1. Alice deletes a word while Bob is typing a letter in the middle of it. What does each of them see a moment later?
2. The collaboration server that owns a busy document crashes. What happens to the people editing it?
3. A 300-page document takes 10 seconds to open. Why, and how would you fix it?

The design in a nutshell

• Clients ↔ WebSocket connection servers ↔ collaboration service; each open document is owned by one collaboration server (consistent hashing on the document ID).
• Clients send small operations tagged with the revision they started from; the owner orders them, transforms concurrent ones (OT) and broadcasts the result. A CRDT is the alternative.
• Each accepted operation is appended to a durable log, partitioned by document ID, before it's acknowledged; snapshots every N operations go to object storage.
• Document metadata and permissions in a relational database; permissions checked on connect and on every write.
• Cursors and presence are broadcast but not stored; clients buffer unacknowledged edits and resend them after reconnecting.

Related lessons: Real-time: polling, long polling, SSE, WebSockets · Inconsistency resolution: versioning and vector clocks · Polling vs long polling vs WebSocket