Realtime Collaboration

balanced

Summary

Sub-100ms state synchronization for collaborative editing, live cursors, presence indicators, and multiplayer game state. Ordering of operations is critical for CRDT convergence and conflict resolution. Fan-out to many connected clients amplifies write load unpredictably.

Example Systems

·Collaborative document editor (Figma, Google Docs)
·Multiplayer game state sync
·Live presence and cursor tracking
·Real-time whiteboard (Miro)
·Collaborative code editor (Replit, CodeSandbox)

Characteristics

CategoryMIXED

Read / write patternbalanced

Latency requirementlow

Consistency requirementsession

Durability requiredNo

Ordering requiredYes

Capacity

Typical RPS5,000

Peak RPS50,000

Typical data volume100 GB

Growth rate5-20 GB/month; operational state is small but event log grows continuously

Seasonal spikes: Large team sessions, product launches with many simultaneous users, and live events (10× multiplier)

Access Patterns

point lookuptime series

Recommended Patterns

leader electionevent sourcingcqrsbulkhead isolation

Patterns to Avoid

two phase commitsharding

Basis

Realtime collaboration systems are well-documented by Figma, Google Docs, and Linear engineering posts; CRDTs add complexity

Related Architecture Knowledge

Outbound: this entity affects

Benefits FromPattern

backpressure

Grounded

Real-time collaboration workloads with unpredictable write bursts benefit from backpressure to prevent the sync server from being overwhelmed by simultaneous edit storms.

Full relationship →

Used In Architecture Scenarios

Gaming Backend Platformhigh

Realtime Collaboration

An online multiplayer game backend built around authoritative server game state synchronization. Game rooms run as distributed state machines where the server is the single source of truth for game state: client predictions are reconciled against the server state at every tick. WebSocket connections provide low-latency bidirectional communication for state deltas. Redis stores active game room state (in-flight, with sub-millisecond access), session affinity tokens (routing players to the same server instance as their game room), and matchmaking queues. PostgreSQL is the durable store for player profiles, persistent inventory, leaderboards, and achievement records. Kafka carries post-game event streams for analytics, anti-cheat processing, and achievement evaluation. NATS provides low-latency pub/sub for intra-cluster game state broadcasting when multiple game server instances must coordinate on shared state. Event sourcing records every game action as an immutable event for replay, dispute resolution, and anti-cheat audit.

Geospatial Tracking Platformhigh

Realtime Collaboration

A real-time location tracking platform for moving entities: vehicles, delivery couriers, field workers, and assets: receiving position updates at 1–30 second intervals from thousands of simultaneously tracked objects. Redis geospatial indexes (GEOADD / GEOSEARCH) serve sub-10ms proximity queries against the live position surface; PostgreSQL stores durable entity metadata and historical location records; TimescaleDB stores high-frequency time-series location data with automatic hypertable chunking and retention policies; Kafka streams location events to downstream consumers (dispatch systems, customer tracking apps, analytics pipelines). Geofence evaluation runs at ingestion time: each incoming position update is tested against active geofences for the entity's region, and geofence entry/exit events are emitted as Kafka messages to downstream consumers.