Design Google Docs: Real-Time Collaborative Editing with OT

Users must be able to create a document and reopen it later from a laptop, phone or another browser. The headline feature is simultaneous editing: several people change the same document at once and watch each other's changes arrive in real time without refreshing.

Presence makes collaboration feel human. Each participant sees who else has the file open and a coloured cursor marking where they are typing. Version history, the ability to view the document as it stood at an earlier moment, is a nice extra that the design will provide almost for free. Comments, permission sharing and detailed rich-text formatting are left out so the discussion stays on the concurrency problem.

Two kinds of latency matter. Local keystrokes must render immediately, with no round trip, otherwise the editor feels broken. Remote collaborators should see those keystrokes within about 200 ms. Convergence is the correctness requirement: once everyone pauses, all copies must be identical. That is eventual consistency, but with a strict guarantee that the end state matches everywhere.

Durability means an edit the server has acknowledged survives any crash. Scale has an unusual shape. There are millions of documents, yet each one has a small editing group, capped at about 100 people. That cap is not arbitrary; it is what makes a single-owner-per-document design feasible, because no single document ever needs more than one machine's worth of throughput.

Assume 1 billion stored documents averaging 50 KB, roughly 50 TB of content. At peak, assume around 2 million people editing concurrently. Clients batch keystrokes, so each editor sends about one operation per second, giving roughly 2 million operations per second across the system.

If each operation is about 100 bytes, the operation log grows at around 200 MB per second, so it must be compacted rather than kept forever in raw form. Yet a single document sees at most a few dozen operations per second even when busy. Huge totals combined with tiny per-document load point straight to partitioning everything by document ID, so that each document's traffic, state and storage stay together.

Four entities define the model. A Document holds metadata. An Operation is one small edit, such as inserting or deleting characters. A Snapshot is a complete saved copy at some version. Presence records who is connected and where their cursor sits.

Ordinary actions use REST: POST /docs with a title returns a doc_id, and GET /docs/{doc_id} returns metadata, the latest content and its version number. Editing runs over a WebSocket at /docs/{doc_id}/edit. The client sends each operation along with the base_version it was applied on top of, plus cursor movements. The server sends back acknowledgements, operations from other editors and their cursor positions. That base version is what lets the server detect and resolve concurrent edits.

Clients reach the system through a gateway that terminates both REST and WebSocket traffic. Routine requests such as creating, listing or sharing files go to a stateless document service. Live editing is different: the gateway consults a coordinator, for example ZooKeeper, to learn which collaboration server currently owns the document, and routes every editor of that file to the same machine.

That owner serialises incoming edits, transforms them where they conflict, appends each to an append-only operation log, and fans it out to the other connected editors. A snapshot worker trails the log and, every few hundred operations, persists a complete copy into blob storage such as S3. Opening a document loads the newest snapshot and replays the short tail of operations after it. Having one owner per document gives a single authority on edit order, which is what makes convergence tractable.

Locking the document or letting the last save win is easy to build, but it silently discards someone's work and is not true co-editing. CRDTs take a different route: each character carries a unique identifier, so replicas can merge in any order without a central authority. That suits offline-first and peer-to-peer apps, but every character drags extra metadata, and deletions leave tombstones that accumulate over time.

Operational transformation with a central server is our choice. Consider two concurrent edits: Alice inserts "X" at index 5 while Bob removes the character at index 2. If the server applies Bob's deletion first, everything after index 2 moves left by one, so Alice's insert must be rewritten as index 4. That rewrite is the transform. Each client submits operations with their base version; the server transforms them past anything newer and assigns the next version.

Libraries such as Yjs and Automerge make CRDTs a legitimate answer too. What interviewers want is the reasoning: since this design already routes each document through one owner, OT keeps both operations and stored data compact.

Follow a single keystroke. The client applies it to its own copy at once so the typist never waits, then sends the operation and its base version over the WebSocket. On arrival, the collaboration server rewrites it to account for operations accepted after that base version and stamps it with the next version number.

Before acknowledging, the server appends the operation to the log, so an acknowledged edit is always durable. It then forwards the operation to every other connected editor, and each of them transforms it against their own not-yet-sent edits before applying it. When the original sender receives its ack, it releases the next operation from its local queue. Allowing only one unacknowledged operation per client at a time keeps transformation logic manageable, because the server never has to reconcile a long chain of speculative edits from one source.

The operation log is the system of record: append-only and keyed by document ID plus version. A wide-column store like Cassandra handles the steady append rate well, and because the key starts with the document ID, each document's history sits in one partition. Snapshots exist purely for speed, so opening a file reads one snapshot and a handful of recent operations instead of replaying years of edits.

Cursors and presence never touch disk. They travel over the same WebSocket and live in the owner's memory; a lost cursor update simply gets replaced by the next one. If a collaboration server fails, the coordinator reassigns its documents. The new owner loads the latest snapshot, replays the log tail, and clients reconnect and resend anything that was never acknowledged. Version history falls out naturally, since older snapshots plus the log can reconstruct any past state.

OT keeps operations small and relies on a central server, whereas CRDTs enable offline and peer-to-peer editing at the price of heavier metadata. Pinning each document to one server makes ordering straightforward, but an extremely busy document cannot spread beyond one machine, which is why the editor cap exists.

Snapshotting more often makes documents open faster while using more storage and background compute. Keeping presence only in memory is cheap and fast, though cursors can briefly jump after a reconnect. The overall recipe: let one owner decide the order of edits, persist every operation before acknowledging it, and lean on periodic snapshots so loading stays quick.