Design collaborative editing (Google Docs)

Suppose the text is 'abc'. Alice inserts 'X' at position 0 and Bob deletes the character at position 2 ('c') at the same moment. If Bob's delete is applied after Alice's insert without adjustment, it deletes 'b' instead, because positions shifted. Operational Transformation fixes this: a function transform(op1, op2) adjusts op1 so it has the same intent after op2 has been applied, here moving Bob's delete to position 3. Generic peer-to-peer OT is notoriously hard to get right (it needs extra properties for correctness), so Google Docs uses a central server: every document has one authoritative sequence of revisions, clients send ops tagged with the revision they were based on, and the server transforms them against ops committed since then. Each client has at most one unacknowledged batch in flight and transforms incoming server ops against its local pending ops. This only needs the simpler transform property between two parties (client and server), which is much easier to implement and test. Rich text adds operation types for formatting (retain with attributes), and tables or lists need careful transform rules. The server-ordered model also gives a clean, linear revision history for free.

A CRDT (Conflict-free Replicated Data Type) makes merging automatic: each character gets a unique, ordered ID (for example based on a logical clock and site ID), and inserts refer to neighbour IDs instead of numeric positions. Deletes mark characters as tombstones. Because operations commute, any replica can apply them in any order and still converge, which needs no central transform server and works well for offline-first and peer-to-peer apps. Yjs and Automerge are production libraries; Figma uses CRDT-inspired ideas for its object model. The costs: metadata overhead per character (much reduced in modern implementations, but still more than plain text), tombstones that grow unless garbage-collected, and interleaving anomalies when two people type at the same position concurrently. In an interview, choose one and justify it. OT with a central server fits a cloud product where everyone is online most of the time and you want one authoritative history. CRDTs fit offline-heavy, local-first or peer-to-peer products. Notably, even CRDT products usually still run a server for persistence, auth and fan-out, so the architecture diagram changes less than people expect.

OT needs a single place that orders ops for a document, and the simplest way is to load each active document into one session server's memory. A routing layer maps doc_id to a server using consistent hashing with a coordination service (etcd or ZooKeeper) holding membership and leases; the load balancer or a thin router sends every WebSocket for that document to its owner. The owner holds the current document state and recent ops in memory, transforms incoming ops, and persists each revision to the op log with a conditional write on revision number. That conditional write is the safety net: if two servers ever believe they own the same document (split brain during a rebalance), only one can append revision N+1, and the loser must reload. Load is naturally spread because there are millions of small documents; the rare hot document (a company-wide doc open by 1,000 people) is still fine for one server because viewers only receive ops. When a server is drained or dies, its documents move to new owners that reload from snapshot plus op log, and clients reconnect and resend their pending ops, which are deduplicated by (client_id, client_seq).

The op log is the source of truth: every committed revision is stored in order, keyed by (doc_id, revision), in a store that handles high-volume appends like Bigtable or Cassandra. Reading a document by replaying millions of ops would be slow, so snapshot workers consume committed ops and periodically write a full serialized document (every ~1,000 ops or 10 minutes of activity) to object storage, recording its revision. Opening a document then reads the latest snapshot plus fewer than ~1,000 ops. Version history is built on the same data: named versions are pointers to revisions, and the history UI groups ops by author and time into human-sized edits. Restoring a version is a new forward operation that sets content to that version, so history is never rewritten and collaborators simply receive it as another change. Old ops can be compacted: keep snapshots at daily granularity and drop fine-grained ops after a retention window to control storage. Comments and suggestions are anchored to positions that are transformed with every op, or to CRDT character IDs, so they stay attached to the right text.

OT needs an authoritative server per document but gives compact ops and linear history, a natural fit for an always-online cloud editor. CRDTs allow any-order merging, offline and peer-to-peer at the cost of metadata, tombstones and some odd interleavings. Both are valid; justify based on offline needs.

Locks (only one person can edit a section) are simple but frustrating and break with offline. Real-time merging gives a much better experience, which is why modern editors use it.

Synchronous append before ack guarantees no lost edits but adds a few ms. Since local edits appear immediately anyway, that latency is invisible, so we persist before ack.

Cursor updates are frequent and ephemeral. Sending them through the session server is simple; they are throttled (e.g. 10/s) and never persisted. A separate presence service is only needed across documents (who is online in the drive).

1,000 viewers and 100 editors on one doc puts all fan-out on one session server. Split viewers onto read-only fan-out replicas that subscribe to the owner's op stream; only editors talk to the owner. Throttle cursor broadcasts.

Millions of appends per second spread across documents partition well by doc_id. Client-side batching of keystrokes into 100 ms ops cuts writes by ~10x.

Snapshot more often for big documents, lazy-load far-away pages, and store images and embeds separately.

Routing assigns the document to a new owner, which loads snapshot plus op log. Clients reconnect, send their pending ops with client_seq; already committed ones are recognised and acknowledged, others are transformed and applied. No acknowledged edit is lost because acks happen after the op log write.

The conditional append on revision number allows only one to commit N+1; the other gets a conflict, drops ownership and redirects clients.

Server validates ops against the document schema before committing; version history allows restoring a good revision quickly.