Back to blog
May 10, 2025

Building a Real-Time Collaborative Editor

A technical deep dive into building a collaborative document editor with CRDTs, WebSockets, and YJS supporting 50+ concurrent users.

crdtwebsocketsreal-time

Building a Real-Time Collaborative Editor

At Cynoia, we built a collaborative document editor that supports 50+ concurrent users editing the same document in real-time. Here is how.

Why CRDTs Over OT?

Operational Transformation (OT) is the classic approach (Google Docs uses it). But CRDTs (Conflict-Free Replicated Data Types) have a significant advantage: they do not require a central server to resolve conflicts.

With CRDTs, each client can apply changes locally and sync them later. Conflicts are resolved automatically by the data structure itself.

Our Stack

  • YJS — A CRDT implementation for shared data types
  • WebSockets (Socket.IO) — Real-time transport layer
  • Redis — Pub/sub for cross-server communication
  • NestJS — Backend framework

The Architecture

Client A ──→ WebSocket ──→ Server 1 ──→ Redis Pub/Sub
Client B ──→ WebSocket ──→ Server 2 ──→ Redis Pub/Sub

Each server maintains a YJS document in memory. Changes from any client are broadcast via Redis pub/sub to all servers, which then forward them to their connected clients.

Performance Optimizations

Multi-Layer Caching

We implemented a three-tier caching strategy:

  1. In-memory — YJS document state for active documents
  2. Redis — Recently accessed documents (TTL: 1 hour)
  3. Database — Persistent storage (PostgreSQL)

This reduced database load by 40%.

Batch Updates

Instead of persisting every keystroke, we batch updates and flush to the database every 5 seconds (or on document close). This dramatically reduced write pressure.

RBAC for Documents

We built granular role-based access control at the document level:

  • Owner — Full control (edit, share, delete)
  • Editor — Can edit content
  • Viewer — Read-only access
  • Commenter — Can add comments but not edit

Permissions are checked on both the WebSocket connection and the HTTP API layer, preventing unauthorized real-time edits.

Key Takeaway

Real-time collaboration is deceptively complex. The editing itself (CRDTs) is the easy part. The hard parts are presence awareness, offline support, permission management, and handling network partitions gracefully.