A Collaborative Editor's Cost Is Per Document, Not Per User

When you build a multiplayer document editor, a docs tool, a design canvas, a shared code file, your cost and your capacity are measured per document, not per user. A million registered users mean nothing to your real-time layer if they are spread across a million documents each edited alone. What costs you is the concurrent editing session: the active document room holding the current state, its participants, and the merge machinery. Size and price your editor on active document rooms, and the scaling picture gets clear and cheap, because most documents, most of the time, have zero or one editor.

The document room is the real unit

A collaborative editor is a collection of rooms, one per open document. Each room holds the authoritative document state, the connected editors, their cursors, and the logic that merges concurrent edits. The room is where all the real-time cost lives: memory for state, CPU for merges, fan-out to participants.

Users, by contrast, are cheap and mostly idle. A user with a document open but not typing is a near-free connection. So counting users tells you almost nothing about load. Counting concurrently active document rooms tells you almost everything. This is scaling rooms, not connections in its most literal form, and it is why a docs product with millions of users can run on modest infrastructure: the concurrent active-room count is a tiny fraction of the user count.

Most documents are solo, and that is a gift

Here is the fact that makes editors cheap to run: the overwhelming majority of documents, at any instant, have zero or one active editor. Real-time merge complexity only kicks in when two or more people edit the same document at the same time, which is rare per document even in a collaborative product.

Exploit that. A solo editing session does not need the full concurrent-merge path; it needs plain autosave and change streaming. Spin up the expensive collaborative machinery, CRDTs or operational transforms and their conflict resolution, only when a room actually has multiple concurrent editors. Keep the common solo case light. Paying merge overhead on every document, including the millions edited alone, is the classic over-build.

Hydrate active rooms, evict idle ones

A room should exist in memory only while a document is actively open. When the last editor leaves, persist the state and evict the room; when someone opens the document again, hydrate the room from storage. This keeps your live footprint proportional to concurrent activity, not to your total document count.

That lifecycle is the crux of editor capacity. Fast hydrate means a document opens instantly; clean eviction means idle documents cost nothing. It is the same discipline as handling reconnection: a returning editor resyncs to authoritative state quickly, whether the room was warm or just rehydrated. Get hydrate-and-evict right and you never pay for the 99 percent of documents nobody is touching.

Sync edits as deltas, keep the durable log aside

Within an active room, editors exchange changes as operations or deltas, not full-document snapshots. Sending deltas, not full state is non-negotiable in an editor: re-sending an entire document on every keystroke is absurd at any size. Each participant applies incoming operations to their local copy, optimistically rendering their own edits and reconciling against the server's authoritative order.

Keep the durable document separate from the live edit stream. The live room carries operations for low latency; a persistence layer writes the settled document and edit history for recovery and version control. This is separating live delivery from the system of record: the room is fast and ephemeral, the store is durable and authoritative when the room is gone.

What to size, and what to build on

To capacity-plan an editor, forecast peak concurrent active document rooms and the average editors per active room, then size room memory and merge CPU against that. User counts are marketing numbers, not capacity inputs. This is the editor-specific version of the connection capacity math: memory per active room, and fan-out within multi-editor rooms, are your real constraints.

A real-time platform like AltoHost gives you room lifecycle, presence, and delta fan-out so you build the editor logic on top instead of the transport and room plumbing underneath. When comparing options, evaluate the real-time backend on how it handles room hydrate and evict and per-room state, because that lifecycle is what makes or breaks editor economics.

Price and scale your editor per document, exploit the solo majority, hydrate active rooms and evict idle ones, and sync deltas over a durable store. Do that and a collaborative editor with millions of users stays genuinely cheap to run. For the room and transport layer, start with AltoHost.