Design Google Docs

Two people edit the same doc simultaneously. What does the client send on each change?

1. Rejected. The whole document on every save.

   Whole-document saves clobber each other — last write wins — and the information about WHAT changed is gone, so you can’t merge intent. Concurrent editing needs the changes themselves.

2. Rejected. A diff against the last saved version.

   Coarse diffs against a stale base still race and lose intent when positions shift, and they’re expensive to merge. You want the fine-grained edits as they happen.

3. The call. Tiny operations: insert/delete at a position.

   Model the doc as an ordered sequence and stream small ops applied locally for instant feedback. Ops preserve intent and are cheap to send, order and merge — the op stream is the source of truth.

A inserts at position 2; B deletes at position 1. By the time A’s op reaches B, positions have shifted. How do they stay identical?

1. Rejected. A global lock so only one person edits at a time.

   Locking kills real-time collaboration — it’s back to "file is locked," the exact thing you’re replacing. Concurrent edits must be allowed and reconciled, not serialized.

2. The call. OT or CRDTs: transform/merge concurrent ops to converge.

   OT rewrites an incoming op against ops it didn’t see (shift A’s "insert at 2" past B’s delete); CRDTs give each char a stable orderable id so edits merge commutatively. Both guarantee convergence — same ops, any order, same doc.

3. Rejected. Apply each op verbatim in arrival order.

   Applying ops blindly when their positions were computed against different states makes the documents diverge permanently. Concurrent ops must be transformed/merged, not applied as-is.

A’s edit is resolved on the server, but B still sees stale text. How does B’s screen update live?

1. Rejected. B polls the server every second for changes.

   Polling is laggy and wasteful — collaboration needs sub-second updates, and most polls return nothing. The server should push the moment an op is accepted.

2. Rejected. B refetches the whole document periodically.

   Re-downloading the doc is heavy, loses B’s cursor/scroll, and still lags. You want just the new ops pushed incrementally, not full reloads.

3. The call. Broadcast each accepted op over WebSockets (pub/sub across servers).

   After accepting an op the server pushes it to every other editor’s open socket; when editors are on different servers, pub/sub relays it to whoever holds each connection. Real-time = push, not poll.

The live doc is in server memory and a long doc has millions of ops. How do you avoid losing work AND loading fast?

1. The call. Append ops to a durable log + periodic snapshots.

   The append-only op log is the truth (nothing lost on a crash); periodic snapshots let you load the latest checkpoint and replay only ops since — fast recovery, full history, free version control.

2. Rejected. Save the full document to disk after every keystroke.

   Rewriting the whole doc per keystroke is enormous write amplification and still loses concurrent intent. Append the small op, and materialize full state only occasionally.

3. Rejected. Keep it in memory and replay all ops on load.

   Memory-only loses everything on a crash, and replaying millions of ops from scratch on every open is far too slow. You need durability (log) plus checkpoints (snapshots).

Colored cursors and "3 people viewing" update constantly and are disposable. How do you handle them?

1. Rejected. Append cursor moves to the op log like edits.

   Persisting a flood of high-frequency cursor updates would swamp the durable log with data nobody replays. Presence is throwaway — it shouldn’t touch document storage.

2. Rejected. Send cursor updates through the same path as ops.

   Mixing disposable cursor traffic into the durable op pipeline risks the document during a presence storm. Keep ephemeral signals on a separate path.

3. The call. A separate ephemeral path: broadcast presence, never persist it.

   Track who’s connected and each cursor/selection, broadcast constantly, but never store it — if everyone leaves, presence evaporates while the doc remains. A cursor flood can’t risk the op log.

A user edits offline in a tunnel, then reconnects — others changed the doc meanwhile. How do the edits merge?

1. The call. Client tracks its last version; sends buffered ops + pulls ops since.

   On reconnect the client sends queued ops and pulls everything from the op log after its last-seen version; OT/CRDT merges the two streams. Offline editing is just real-time editing with a longer delay — same convergence machinery.

2. Rejected. Last writer wins — overwrite with the offline copy.

   Overwriting discards everyone else’s changes made while the user was offline. Concurrent edits must merge, not clobber — exactly what OT/CRDT exists to do.

3. Rejected. Block editing until the connection returns.

   Forbidding offline edits breaks the experience on planes and in tunnels, and isn’t necessary — buffered ops plus version-based catch-up merge cleanly on reconnect.