Case study 02 / 04
Distributed systems · 2026
Sync Engine
Real-Time Collaborative Sync Engine
Many editors, one consistent document.
- Type
- Distributed systems
- Year
- 2026
- Status
- Open source
- Core stack
- Java 21, Spring Boot, Spring WebSocket
01Overview
Overview
A distributed, event-driven editing platform where many people edit the same document at once. Operational Transformation keeps every copy consistent, and Kafka event sourcing makes every document recoverable.
Average latency at 500 concurrent users
Messages received in the 500-user run
Spring Boot nodes behind one hash ring
02The problem
Collaborative editing needs strict conflict resolution, low latency and horizontal scaling at the same time. Drop any one of them and concurrent edits make replicas drift apart under load.
03The approach
Clients connect over WebSocket and STOMP to a cluster of Spring Boot nodes. Each document is routed through a consistent hash ring to an owner node, whose OT engine transforms the operation and bumps the version. The event is appended to Kafka and broadcast through Redis Pub/Sub, so every node and every client converges.
04How it works
How an edit converges
- 01
Route
Document ID to consistent hash ring to owner node, so every operation on a document is ordered in one place.
- 02
Transform
The OT engine transforms the incoming operation against concurrent ones and returns a new document version.
- 03
Persist
The operation is appended to Kafka, the event store behind replay and recovery.
- 04
Broadcast
Redis Pub/Sub fans the update out to every node and every connected client.
05Under the hood
Under the hood
01
Snapshot plus replay recovery
A snapshot service writes document state to PostgreSQL. After a crash, recovery loads snapshot 100, replays events 101 to 104 and lands exactly on version 104.
02
Presence and live sync
Multi-user editing with presence tracking and real-time broadcasting over WebSocket and STOMP.
03
Observable by default
Actuator exports active users, active documents, operations processed, JVM memory, CPU and WebSocket connections to Prometheus and Grafana.
06Results
Collaborative load test
| Concurrent users | Messages sent | Messages received | Average latency |
|---|---|---|---|
| 100 | 2,400 | 170,407 | 45 ms |
| 250 | 6,000 | 435,000 | 72 ms |
| 500 | 12,000 | 910,000 | 118 ms |
Measured with the project's own collaborative load-testing harness against the three-node cluster.
07What comes next
What comes next
- 01CRDT-based synchronization alongside OT.
- 02Leader election and automatic failover.
- 03Dynamic service discovery and auto-scaling.
- 04Multi-region deployment.
08Stack
Technology stack
- Java 21
- Spring Boot
- Spring WebSocket
- STOMP
- Apache Kafka
- Redis
- PostgreSQL
- Prometheus
- Grafana
- Docker
- Kubernetes
- GitHub Actions
- k6
- Swagger / OpenAPI