WebSockets provide the real-time transport; CRDTs and operational transformation solve concurrent editing. Use a CRDT when offline editing and peer-to-peer convergence matter, and operational transformation when a central server can order operations. Transport scaling and conflict resolution are separate design problems and should be solved separately.
Transport and connection management
WebSockets give bidirectional low-latency messaging over a single connection. Server-sent events provide one-way streaming and are simpler where the client only needs updates. Polling remains useful for low-frequency updates where connection overhead is not justified.
Connections are stateful, which changes scaling. Each connection consumes memory on a specific server, so clients for the same document must be routed to the same coordination point, or servers must exchange messages through a shared bus. Choose deliberately between sticky routing, a pub-sub backbone or a dedicated collaboration service.
Handle reconnection as a first-class concern. Mobile networks drop connections constantly, so clients need exponential backoff with jitter, resumable sync from the last acknowledged version, and a clear indication of connectivity state in the interface.
- Choose transport by direction and frequency, not by novelty.
- Route clients by document or use a shared pub-sub backbone.
- Implement resumable sync from the last acknowledged version.
- Use exponential backoff with jitter on reconnect.
CRDTs and operational transformation
Operational transformation transforms concurrent operations so they can be applied in a single canonical order, typically enforced by a central server. It works well in centralised systems and produces compact documents, but the transformation logic is intricate and correctness is difficult to prove.
CRDTs define data types whose merge operation is commutative and idempotent, so replicas converge regardless of the order in which operations arrive. That makes offline editing and peer-to-peer synchronisation straightforward, at the cost of metadata overhead and more complex data structures.
For most product teams the practical question is whether offline editing is required. If it is not, server-ordered operational transformation with a central authority is usually simpler to reason about. If offline or multi-device convergence is required, a CRDT removes an entire class of problems.
| Aspect | Operational transformation | CRDT |
|---|---|---|
| Coordination | Central ordering required | None required |
| Offline editing | Difficult | Natural fit |
| Document size | Compact | Larger metadata overhead |
| Complexity | Intricate transformation logic | Complex data types, simpler merge |
| Peer to peer | Impractical | Supported |
| Best fit | Centralised editors, live only | Offline-first, multi-device |
Presence and persistence
Presence, cursors and typing indicators are ephemeral. They should be transmitted over a lossy fast path, expire automatically, and never be persisted as authoritative state. Treating presence as durable data creates staleness bugs that are difficult to reproduce.
Document content is the opposite: it must be durable, versioned and recoverable. Persist operations with enough frequency that a crash loses seconds rather than minutes, and keep periodic snapshots so a new client can load state without replaying an unbounded operation log.
Define retention for the operation log. Compaction and snapshotting keep the log bounded, and the retention policy determines how far back you can restore or audit.
- Keep presence ephemeral with automatic expiry.
- Persist operations frequently and snapshot periodically.
- Compact the operation log so it stays bounded.
- Define retention for reconstruction and audit.
Scaling and permissions
Fan-out is the core scaling constraint. A document with two hundred concurrent editors concentrates load on one coordination point, whereas a million independent documents scale horizontally. Design for the hot-document case explicitly: rate-limit high-frequency messages, batch updates and consider degrading presence fidelity before degrading document correctness.
Permissions must be enforced on every message, not only when the connection is established. A user whose access is revoked mid-session must stop receiving updates immediately, which means the authorisation check belongs in the message path.
Log who changed what and when. In collaborative systems, the question of who made a change is asked routinely, and an operation log with actor attribution answers it without a separate audit trail.
- Design explicitly for hot documents with many concurrent editors.
- Rate-limit and batch high-frequency messages such as cursor moves.
- Re-check authorisation on every message, not only at connect.
- Attribute every operation to an actor in the log.
Frequently asked questions
Should I use CRDTs or operational transformation?
Use CRDTs when offline editing or multi-device convergence is required, because replicas converge without central ordering. Use operational transformation when editing is live and a central server can order operations, since it produces compact documents with simpler merge semantics.
How do you scale WebSocket connections?
Route clients of the same document to the same coordination point or exchange messages through a shared pub-sub backbone, then design specifically for hot documents with many concurrent editors by rate-limiting and batching high-frequency messages.
Should presence be stored in the database?
No. Cursors, typing indicators and online status are ephemeral and should expire automatically. Persisting them as authoritative state creates staleness defects that are hard to reproduce.
References
Engineer your next strategic platform
Estimate your project investment and delivery timeline instantly, or schedule an architectural discovery call with our engineering leadership.