Design the backend for a real-time collaborative document editor (think a shared rich-text doc that many people can type in at once). Multiple people open the same document, type simultaneously, see each other's edits and cursors within a fraction of a second, and never lose work — even when someone edits on a train with no signal and reconnects an hour later.

Operating context. A B2B workspace product. ~5M documents, ~40M total edit ops/day, but heavily skewed: the median doc has 1 active editor while a small tail of "hot" docs (meeting notes, planning boards) have 20–50 concurrent editors during business hours. Edits are tiny (a keystroke, a formatting toggle) and arrive in bursts. A doc's steady-state edit fan-out must land on every other participant at p99 < 200 ms in-region. Documents live for years and accrete a long edit history.

Out of scope. The rich-text rendering / WYSIWYG client, auth and sharing-permission policy (assume an upstream service hands you an authenticated userId + docId with write rights), full-text search across docs, comments/suggestions mode, and export to PDF/Word. Assume separate teams own those.

What to produce. A high-level architecture covering: the edit ingest + real-time fan-out path (transport and per-doc routing), the concurrency-control model — pick OT or CRDT and defend it against the alternative, how presence and live cursors propagate cheaply, the persistence model (op log vs snapshots, a compaction/snapshot strategy so replay stays bounded, and how history is retained for viewing or restoring an earlier version), the offline-edit + reconnect-and-merge story, and how a single hot document scales when one server can't hold all its editors. Sketch the major components and the request/edit flow between them; we will probe specifics at each checkpoint.