Design a Real-Time Collaborative Whiteboard

High-level plan for a real-time collaborative whiteboard 1. Goals and assumptions - Support 50+ concurrent users on one board. - End-to-end update visibility under 500 ms. - Operations: freehand strokes, text boxes, rectangles/circles, move/resize/delete. - Strong responsiveness while keeping all users’ views eventually consistent. - Prefer availability and low latency over strict global ordering. 2. High-level architecture Client applications - Web/mobile whiteboard UI. - Local rendering engine using Canvas/WebGL/SVG. - Input capture layer for pointer/mouse/touch events. - Local operation buffer and optimistic application. - Real-time sync module over WebSocket. - Snapshot/cache store for current board state. API and session layer - HTTPS API for auth, board discovery, permissions, loading initial board snapshot, exporting board. - WebSocket gateway for real-time session traffic. Collaboration backend - Session coordinator service: tracks connected users per board, presence, cursors, and routing. - Operation processor: validates ops, assigns sequence metadata, persists event log, broadcasts to participants. - Conflict-resolution layer: applies ordering/idempotency rules and object-level merge policies. Storage layer - Persistent event log for board operations. - Periodic board snapshot store for fast load. - Metadata DB for users, boards, ACLs, session info. - Optional in-memory cache (e.g. Redis) for hot sessions, presence, ephemeral cursor state. 3. Client-side design Rendering model - Represent board as a scene graph of objects: - Stroke - TextBox - Shape - Each object has stable object_id, z_index, style, transform, created_by, timestamps/version. - For freeform drawing, client samples points and smooths locally for immediate feedback. Local-first behavior - User actions are applied immediately on the client for low perceived latency. - Client sends operations asynchronously to server. - Server acknowledgments reconcile local pending ops with canonical ordering. Client modules - Presence/cursor module: sends lightweight cursor/selection updates at throttled intervals. - Sync engine: handles reconnect, resend, deduplication, and catch-up from last acknowledged sequence. - State manager: keeps confirmed state + pending local ops. 4. Server-side design 4.1 WebSocket gateway - Maintains persistent bidirectional connections. - Authenticates user and authorizes board access. - Routes messages by board/session ID. - Can be horizontally scaled; sticky sessions help but are not required if session state is externalized. 4.2 Session coordinator - Maintains membership for each board session. - Publishes join/leave, cursor presence, and selection state. - Uses Redis pub/sub or a message bus so all gateway instances can broadcast to participants in the same board. 4.3 Operation processor - Receives client operations. - Validates schema, board permissions, object existence, and rate limits. - Assigns server sequence number per board. - Writes operation to append-only event log. - Updates in-memory board state or snapshot cache. - Broadcasts canonical operation to all connected users. 4.4 Snapshot builder - Periodically compacts event log into board snapshots. - Trigger snapshot creation every N operations or T seconds. - On board load, clients fetch latest snapshot + tail of operations after snapshot version. 5. Communication protocol Use WebSocket for real-time updates - Best fit for low-latency bidirectional communication. - Supports frequent small messages: strokes, transforms, cursor movement, acks. - Fallback to HTTP polling only if required, but WebSocket is primary. Use HTTPS/REST (or GraphQL) for non-real-time flows - Login/auth. - Fetch board metadata. - Fetch latest snapshot/history. - Create board/session. - Export/import. Example WebSocket message types - join_board {board_id, last_seq_seen} - op_create_object - op_append_stroke_points - op_update_object - op_delete_object - op_reorder_object - cursor_update - selection_update - ack {server_seq} - snapshot_required / resync 6. Data model and persistence 6.1 Logical board model Board - board_id - owner/team - permissions - latest_seq - snapshot_version - created_at, updated_at Drawable object - object_id - type: stroke | textbox | rectangle | circle - version - z_index - style: color, width, fill, font, etc. - geometry: - stroke: list of points or compressed path segments - textbox: x, y, width, height, text content - shape: x, y, width, height, rotation - deleted flag or tombstone Operation/event - op_id (UUID for idempotency) - board_id - actor_id - client_id - client_op_seq - server_seq - timestamp - op_type - payload - base_version or dependency metadata 6.2 Persistence strategy Event sourcing + snapshots - Persist every user action as an immutable operation in an event log. - Store periodic materialized snapshots for fast board reconstruction. - Benefits: - Easy replay and audit trail. - Simpler synchronization and recovery. - Good fit for collaborative timelines. Suggested storage split - Metadata in relational DB. - Event log in durable append-friendly storage (SQL table, Kafka + DB sink, or NoSQL log store). - Snapshots in object storage or document store. - Redis for ephemeral presence and hot board state. 7. Real-time synchronization strategy 7.1 Operation-based sync - Clients send semantic operations, not full canvas bitmaps. - Examples: - Create rectangle - Append points to stroke S - Update text of textbox T - Move shape X by delta - Delete object Y - This keeps bandwidth low and makes merges manageable. 7.2 Sequencing model - Server assigns a monotonically increasing server_seq per board. - Canonical broadcast order is by server_seq. - Clients track last_seq_seen. - On reconnect, client requests missing ops since last_seq_seen. 7.3 Optimistic UI - Client applies its own op immediately. - Marks it pending until acked with server_seq. - If server transforms/rejects op, client reconciles by rebasing pending ops on top of canonical state. 7.4 Batching and throttling - Freehand drawing generates many points, so batch points every 20–50 ms or after N points. - Cursor updates are ephemeral; throttle to ~20–30 Hz and do not persist. - This reduces load while preserving real-time feel. 8. Conflict resolution Because a whiteboard contains many independent objects, use object-level conflict handling rather than a single global lock. 8.1 Recommended approach Use an operation-based model with per-object versioning and simple OT/CRDT-inspired rules depending on object type. A. Independent object creation - Concurrent creates never conflict. - Each object gets globally unique object_id. B. Strokes - Treat each stroke as append-only during drawing. - A stroke is usually owned by its creator while in active drawing state. - Other users typically cannot mutate the same in-progress stroke. - Once completed, edits become separate ops (move, style change, delete). - This greatly reduces conflict complexity. C. Shapes and text boxes - Use per-object versions. - Updates include base_version. - If base_version matches current version, apply directly. - If not, resolve by field-level merge when possible: - Position and size edits: last-writer-wins or transform composition if operations are commutative. - Style changes on different fields can merge. - Text content: use a text CRDT/OT if simultaneous text editing inside the same textbox is a required experience. - If rich simultaneous text editing is not core, simplify by allowing one active editor lock per textbox. D. Delete vs update - Delete wins over stale updates unless update has a later server_seq and object supports undeletion/version restore. - Keep tombstones briefly so late operations can be identified and ignored safely. 8.2 Practical conflict policy for this system For a medium-complexity whiteboard, a pragmatic policy is: - Board-level ordering by server_seq. - Object-level version checks. - Last-writer-wins for shape/textbox transforms and style if edits collide. - Soft lock or single-editor lease for active textbox content editing. - Append-only stroke creation with creator ownership while drawing. This is simpler than full-board OT and works well for whiteboards, where most edits target different objects. 9. Handling scale for 50 concurrent users per board Why this is feasible - 50 users is moderate if messages are compact and ephemeral traffic is throttled. Techniques - One session shard per board in memory/cache for fast fan-out. - WebSocket fan-out through pub/sub. - Batch stroke points. - Compress messages with permessage-deflate if useful. - Avoid persisting cursor/presence noise. - Snapshot often enough to avoid long replay times. Capacity considerations - Hot board state in memory: current object map, latest seq, participant list. - Broadcast path should be O(users in board), which is fine for 50 users. - If sessions grow larger later, add regional edge gateways and partition sessions across collaboration workers. 10. Failure handling and reliability - Every op has op_id for deduplication on retries. - Client reconnects with last_seq_seen and receives missed ops. - If gap is too large or snapshot expired, server instructs full resync from latest snapshot. - Event log provides durability if collaboration worker crashes. - Presence state is ephemeral and rebuilt on reconnect. 11. Latency strategy to stay under 500 ms - WebSocket persistent connections avoid request setup cost. - Client-side optimistic rendering gives near-instant local response. - Collaboration servers keep hot session state in memory. - Regional deployment places users near nearest gateway. - Batching balances throughput and delay; use small flush intervals for strokes. - Broadcast from memory/cache rather than rereading database on each update. 12. Security and access control - Authenticated WebSocket upgrade using token/cookie. - Board-level ACL: owner/editor/viewer roles. - Server validates every operation against permissions. - Rate limiting per client to prevent abuse or accidental floods. 13. End-to-end flow example - User opens board via HTTPS and fetches latest snapshot + tail ops. - Client establishes WebSocket and sends join_board with last_seq_seen. - User draws a line; client renders instantly and sends batched append_stroke_points ops. - Server validates, assigns server_seq, appends to event log, updates session state, broadcasts to all users. - Other clients receive ops and render the stroke incrementally. - If one client disconnects, it reconnects and requests ops since its last seen sequence. 14. Recommended final design choice - Client: local-first canvas renderer + optimistic op buffer. - Server: WebSocket gateways + collaboration/session service + append-only op log + snapshots. - Protocol: WebSocket for real-time ops/presence, HTTPS for board load and admin APIs. - Consistency model: server-ordered operations with object-level versioning. - Conflict resolution: append-only strokes, simple merge/LWW for shapes, optional lock or CRDT for textbox content. This design is straightforward to build, meets near-real-time collaboration needs, and scales comfortably to 50 concurrent users per whiteboard while keeping synchronization and conflict handling manageable.

# Real-Time Collaborative Whiteboard System Design ## High-Level Architecture Overview The system consists of three main layers: client-side rendering and interaction, real-time communication infrastructure, and server-side state management with persistence. ## Key Components ### Client-Side Architecture 1. **Canvas Rendering Engine**: WebGL or Canvas 2D API for efficient drawing and rendering of all whiteboard elements 2. **Local State Manager**: Maintains a local copy of the canvas state for immediate visual feedback 3. **Input Handler**: Captures user interactions (mouse/touch events) and converts them to drawing operations 4. **WebSocket Client**: Establishes persistent bidirectional connection to the server 5. **Conflict Resolution Layer**: Applies operational transformation or CRDT logic locally before sending to server 6. **Undo/Redo Manager**: Maintains operation history for local undo/redo functionality ### Server-Side Architecture 1. **WebSocket Server**: Handles multiple concurrent client connections using Node.js with Socket.io or native WebSocket 2. **Session Manager**: Maintains active whiteboard sessions and user presence information 3. **Operation Log**: Stores all drawing operations in order of receipt 4. **State Reconciliation Engine**: Applies operations to canonical canvas state and broadcasts updates 5. **Conflict Resolution Service**: Implements operational transformation or CRDT to handle concurrent edits 6. **Persistence Layer**: Stores whiteboard snapshots and operation logs in database 7. **Cache Layer**: Redis for fast access to active session states ## Communication Protocol **Protocol**: WebSocket with JSON message format **Message Types**: - `draw_operation`: {userId, operationId, type, coordinates, color, strokeWidth, timestamp} - `add_shape`: {userId, operationId, shapeType, position, dimensions, style, timestamp} - `add_text`: {userId, operationId, text, position, fontSize, color, timestamp} - `delete_element`: {userId, operationId, elementId, timestamp} - `cursor_position`: {userId, x, y} (for awareness) - `ack`: {operationId} (acknowledgment of receipt) - `sync_request`: {userId, lastKnownVersion} - `full_state`: {version, elements, operations} **Latency Optimization**: - Use binary protocol (MessagePack) for smaller payload sizes - Implement message batching: collect operations for 50ms before sending - Use delta compression for state updates - Target: <500ms end-to-end latency through optimized server processing and CDN-distributed WebSocket servers ## Data Modeling **Canvas Element Schema**: ``` Element { id: UUID, type: 'line' | 'rectangle' | 'circle' | 'text', userId: string, createdAt: timestamp, updatedAt: timestamp, version: number, data: { // For lines: points array [{x, y}, ...] // For shapes: {x, y, width, height, rotation} // For text: {x, y, content, fontSize, fontFamily, color} }, style: {color, strokeWidth, opacity, ...} } ``` **Operation Schema**: ``` Operation { id: UUID, sessionId: string, userId: string, type: 'create' | 'update' | 'delete', elementId: string, timestamp: number, lamportClock: number, payload: {...}, clientId: string } ``` ## Real-Time Synchronization Strategy ### Operational Transformation (OT) Approach 1. **Operation Ordering**: Use Lamport clocks combined with userId to establish total ordering of concurrent operations 2. **Transform Function**: When two operations conflict, transform them against each other: - If user A draws a line and user B adds text at same time, both operations are preserved - Transformation ensures final state is consistent across all clients 3. **Server as Authority**: Server receives operations, assigns Lamport clock values, transforms against concurrent operations, and broadcasts canonical version 4. **Client-Side Prediction**: Clients apply operations optimistically with temporary IDs, then reconcile when server confirms ### Conflict Resolution Process 1. **Detection**: Server identifies concurrent operations (received within same time window) 2. **Transformation**: Apply OT transformation rules: - Position-based conflicts (two shapes at same location): preserve both, adjust positions slightly - Text conflicts: maintain insertion order based on Lamport clock - Delete conflicts: last-write-wins with timestamp tiebreaker 3. **Broadcast**: Send transformed operations to all clients with canonical version number 4. **Client Reconciliation**: Clients compare local version with server version; if mismatch, request full state sync ### Handling 50 Concurrent Users 1. **Horizontal Scaling**: Deploy multiple WebSocket servers behind load balancer 2. **Session Sharding**: Each whiteboard session assigned to specific server instance 3. **Redis Pub/Sub**: For cross-server communication if session spans multiple servers 4. **Operation Batching**: Group operations into batches of 10-20 before processing 5. **Lazy Evaluation**: Only render visible canvas area; defer off-screen rendering 6. **Connection Pooling**: Reuse database connections for persistence writes ## Persistence Strategy 1. **Operation Log**: Append-only log of all operations stored in database - Enables full reconstruction of any historical state - Supports audit trail and undo functionality 2. **Periodic Snapshots**: Every 1000 operations or 5 minutes, create canvas snapshot - Reduces recovery time on server restart - Stored in database with version number 3. **Asynchronous Writes**: Persist operations to database after broadcasting to clients - Prevents persistence from blocking real-time updates - Use write-ahead logging for durability 4. **Data Structure**: Store in document database (MongoDB) or time-series database for efficient querying ## Scalability Considerations - **Memory**: Cache active sessions in Redis; evict inactive sessions after 30 minutes - **Network**: Implement message compression; use CDN for static assets - **Database**: Index by sessionId and timestamp for fast queries; archive old sessions - **Monitoring**: Track operation latency, connection count, and conflict rate ## Security Measures - Authenticate users before allowing session access - Validate all operations on server side - Implement rate limiting per user (max 100 operations/second) - Encrypt data in transit (WSS) and at rest - Implement access control for session permissions This design balances real-time responsiveness with consistency and scalability, enabling smooth collaboration for up to 50 concurrent users with sub-500ms latency.