Collaborative Editor System Design
Learn how a real-time collaborative editor keeps multiple people on the same document without making typing feel slow.
Continue with the guided workspace
Use the paired workspace to connect this guide's mental model with live component state, visible signals, and the outcome each step or scenario is meant to prove.
Mental Model
If you are new to collaborative editors, focus on one question first: how can two people type at nearly the same time and still end up with the same document?
Think of the editor as three jobs happening at once:
- The browser keeps the typing experience fast for the local user via optimistic updates.
- The collaboration server decides the shared order of edits.
- Storage systems keep enough history and state so the document can be restored, replayed, and synchronized later.
Components and Why They Exist
Client (Browser)
This component exists to give the user a fast, interactive editor workspace. It registers key presses, renders optimistic updates instantly, manages local edit queues, and syncs cursor positions. In the demo, watch client nodes display character entries instantly and buffer offline edits when network connection is severed.
Load Balancer
This component exists to distribute websocket connections and route concurrent collaborators to the same server node. It inspects incoming connection requests, maps document identifiers to backend targets, and holds persistent WebSocket routing rules. In the demo, watch WebSocket connection routes established through the load balancer.
Collaboration Server
This component orders edits, commits them to storage, and broadcasts updates. In the demo, watch the server process edits, transform indexes, and broadcast updates to peer clients.
Operation Log (Oplog) & Document Store
This component exists to persist history logs for disaster recovery and document snapshots for faster onboarding. The Oplog saves sequential changes as they happen, while the Document Store takes snapshot backups at specific intervals. In the demo, watch operations written to the Oplog and snapshots stored in the Document Store.
Redis Presence Store
This component exists to handle temporary, rapidly changing metrics like user mouse positions. It tracks cursor coordinates, text selections, and client heartbeats, skipping persistent databases. In the demo, watch cursor presence details updated inside the Redis node.
Edge Cases and Misconceptions
Operational Transformation (OT) Complexity
OT is notoriously difficult to implement for rich text because formatting modifications (bolding, headers) combined with insertions and deletions create complex intersection states. If any edge cases are missed, different client views will drift and never converge.
CRDT Storage Overhead
While CRDTs don’t require a central server for transformation, they attach unique metadata (client IDs, vector clocks) to every character, which dramatically increases memory usage compared to plain text. Garbage collection strategies are required to clean up deleted character metadata.
Common Questions
What is the difference between Operational Transformation (OT) and Conflict-free Replicated Data Types (CRDTs)?
OT relies on a central server to coordinate and transform incoming operation indices based on concurrent operations. CRDTs use mathematically designed structures where each item has a globally unique ID, allowing replicas to merge edits deterministically without a central coordinating server.
Why use WebSockets here?
Because the editor needs a live two-way connection. The browser can send each edit immediately, and the server can push updates back without waiting for the client to ask again.
Why do snapshots matter if we already have an operation log?
Because replaying every old edit gets slower as the document grows. A snapshot gives new or returning clients a recent full copy, so they only need to replay the newer operations after that checkpoint.
What does Redis do in this design?
It stores fast-changing presence data such as cursors, selections, and active sessions. That information changes constantly and usually does not need the same long-term storage as the document itself.
How does offline editing work in a collaborative editor?
While offline, the client buffers all user edits locally in an operations queue. When the connection is restored, the client sends this backlog to the server, which merges them into the shared state and broadcasts updates to catch the client up.