Real-Time Collaboration Feature Design Template

CRDTs (Yjs, Automerge) are generally the better choice for new projects. They handle conflicts automatically without a central server, support offline editing natively, and have excellent open-source libraries. OT requires a central server to transform operations and is harder to implement correctly. OT is better when you need fine-grained server-side control over every operation (e.g., for compliance or validation). For most product teams, CRDTs with a library like Yjs are the pragmatic choice. Document the decision in an [ADR](/templates/architecture-decision-record-template).

It depends on your architecture and operation frequency. A well-optimized WebSocket relay server can handle 50-100 concurrent editors per document with sub-200ms latency. Beyond 100 editors, consider sharding the document or switching to a view-only mode for overflow participants. Google Docs supports up to 100 editors. Figma supports hundreds of viewers with a smaller set of active editors. Design your system for your actual use case, not theoretical maximums.

For small scale (< 1,000 concurrent connections), your existing server can handle WebSocket connections. Beyond that, use a dedicated WebSocket server or a managed service (AWS API Gateway WebSocket, Ably, Pusher, Liveblocks). WebSocket connections are long-lived and stateful, which requires different scaling patterns than stateless HTTP [REST APIs](/glossary/rest-api). A dedicated WebSocket server can scale independently from your API server.

With CRDTs, offline editing is native. Operations are applied locally and queued. When the user reconnects, queued operations are synced and merged automatically. With OT, offline support is harder because operations must be transformed against the server state. For most products, supporting a brief offline period (< 5 minutes) and showing a "reconnecting" indicator is sufficient. Full offline editing (hours or days) requires CRDTs. ---