A look at how Google Docs works. Google Docs lets two people edit the same paragraph at the same time without overwriting each other, and the architectural decision that makes that possible is Operational Transformation (OT), a server-side algorithm that takes concurrent edits from multiple users and serializes them into a single consistent document state. CRDTs get the hype in 2026, but Docs has been doing OT in production since 2006.
How Google Docs Works: The problem at scale
Collaborative editing has a fundamental distributed-systems problem: if Alice and Bob both edit the same paragraph simultaneously, both edits need to land without clobbering each other. A naive “last write wins” model loses one edit. A naive “lock the document while editing” model kills the collaboration feel. The right answer is some form of conflict resolution that lets both edits land in a way both users see as correct. OT and CRDTs are the two main approaches; Google Docs chose OT in 2006 and has been refining it for 20 years.
The core architecture
Every keystroke in Google Docs is an operation: insert character X at position N, delete range M to N, apply formatting Y to range. Operations go from the editor to the Operation Queue (per-document FIFO), then to the OT Server, the brain. The OT server’s job: take concurrent operations from multiple users, transform them so they can be applied in any order with the same result, and broadcast the transformed operations to all clients. Every few seconds or every N operations, the Snapshot Service writes a checkpoint to Colossus (Google’s distributed filesystem), so re-opening a doc doesn’t require replaying every keystroke ever typed.
Operational Transformation explained
The core insight: if Alice inserts “Hello” at position 5, and Bob simultaneously inserts “World” at position 5, applying them in arrival order would have one overwrite the other. OT instead defines a transform function: given two concurrent operations, produce two new operations that can be applied in either order with the same final state. The server transforms Bob’s op against Alice’s, applies both, and broadcasts the transformed version to both clients. Both Alice and Bob see “Hello World” appear, in the right positions, without either of them losing data.
The math is well-understood (it dates to the 1989 Ellis-Gibbs DIXIE paper), but implementing it for rich text with formatting, images, comments, suggestions, and tables is fiendishly hard. Google has 20 years of bug fixes in their OT implementation, which is part of why no competitor has caught up.
Why not CRDTs (yet)
CRDTs (Conflict-free Replicated Data Types) have become the fashionable answer in the last 5-10 years: Automerge, Yjs, and similar libraries offer OT-like behavior without a central server. The trade-off: CRDTs are simpler operationally (no central OT server to maintain) but more expensive (each operation carries more metadata), and historically they’ve been harder to retrofit onto rich text. Google Docs was built on OT before CRDTs were mature enough for production, and the migration cost (20 years of OT-tuned features) is enormous. New collaborative editors (Notion, Linear, some parts of Office) use CRDTs; Google Docs and older Microsoft Word online use OT.
The one non-obvious insight
The OT server is stateful per document, which is unusual for a Google-scale service. Most Google infrastructure is stateless-and-sharded; Docs requires per-document sequencing, which means a specific server “owns” each doc at any moment. The routing layer figures out which OT server holds doc X and routes the user’s connection there. When that server fails, a backup takes over by replaying the operation log from Colossus. The operational complexity of running stateful servers at Google scale is the hidden cost of OT, and the reason CRDTs, which don’t need a stateful server, are gaining ground.
Google Docs is the canonical OT (Operational Transformation) implementation: stateful per-document servers transform concurrent ops so they apply in any order, snapshots checkpoint to Colossus periodically. The architecture has run in production for 20 years; CRDTs are the future, but OT’s reliability advantage is enormous.
Continue learning: