✏️ Explanatory Question
The core constraint: multiple users edit the same document simultaneously, everyone must converge on the same final state, and no edit may be lost.
Connection layer - WebSockets, not HTTP polling, because updates must be pushed with sub-100 ms latency. This makes the connection tier stateful, which is the first architectural consequence: a load balancer must route all collaborators on one document to the same server, typically by consistent hashing on document ID.
Conflict resolution - the heart of the problem. Two approaches:
Persistence - do not write the full document on every keystroke. Append operations to a log, and periodically write a compacted snapshot. The document state is snapshot plus subsequent operations, which also gives version history and undo for free.
Supporting pieces: a presence service for cursors (ephemeral, in Redis with a TTL, never persisted), a Pub/Sub layer so servers holding the same document can broadcast to each other, and an access-control service.
State the trade-off: stateful connection servers make deployment harder - you need connection draining and client reconnect-with-resume logic, because a deploy disconnects every active editor.