Entwerfen Sie ein Echtzeit-Whiteboard für die Zusammenarbeit

Hochrangiger Plan für ein kollaboratives Echtzeit-Whiteboard 1. Ziele und Annahmen - Unterstützung von über 50 gleichzeitigen Benutzern auf einem Board. - Sichtbarkeit von Ende-zu-Ende-Updates unter 500 ms. - Operationen: Freihandstriche, Textfelder, Rechtecke/Kreise, Verschieben/Größenänderung/Löschen. - Hohe Reaktionsfähigkeit bei gleichzeitiger Gewährleistung der eventually consistency für alle Benutzeransichten. - Bevorzugung von Verfügbarkeit und geringer Latenz gegenüber strenger globaler Ordnung. 2. Hochrangige Architektur Client-Anwendungen - Web/Mobile Whiteboard-UI. - Lokale Rendering-Engine mit Canvas/WebGL/SVG. - Input-Erfassungsschicht für Zeiger-/Maus-/Touch-Ereignisse. - Lokaler Operationspuffer und optimistische Anwendung. - Echtzeit-Synchronisationsmodul über WebSocket. - Snapshot/Cache-Speicher für den aktuellen Board-Zustand. API- und Session-Schicht - HTTPS-API für Authentifizierung, Board-Discovery, Berechtigungen, Laden von anfänglichen Board-Snapshots, Exportieren von Boards. - WebSocket-Gateway für Echtzeit-Session-Traffic. Kollaborativer Backend - Session-Koordinator-Dienst: verfolgt verbundene Benutzer pro Board, Präsenz, Cursor und Routing. - Operationsprozessor: validiert Operationen, weist Sequenzmetadaten zu, speichert Event-Protokoll, sendet an Teilnehmer. - Konfliktlösungs-Schicht: wendet Ordnungs-/Idempotenzregeln und Objekt-Level-Merge-Richtlinien an. Speicher-Schicht - Persistentes Event-Protokoll für Board-Operationen. - Periodischer Board-Snapshot-Speicher für schnelles Laden. - Metadaten-DB für Benutzer, Boards, ACLs, Session-Infos. - Optionaler In-Memory-Cache (z. B. Redis) für heiße Sessions, Präsenz, ephemere Cursor-Zustände. 3. Client-seitiges Design Rendering-Modell - Board als Szenengraph von Objekten darstellen: - Strich - Textfeld - Form - Jedes Objekt hat eine stabile object_id, z_index, Stil, Transformation, created_by, Zeitstempel/Version. - Für Freihandzeichnungen sammelt der Client lokal Punkte und glättet sie für sofortiges Feedback. Lokales Verhalten - Benutzeraktionen werden sofort auf dem Client angewendet, um eine geringe wahrgenommene Latenz zu erzielen. - Der Client sendet Operationen asynchron an den Server. - Server-Bestätigungen gleichen lokale ausstehende Operationen mit der kanonischen Reihenfolge ab. Client-Module - Präsenz/Cursor-Modul: sendet leichtgewichtige Cursor-/Auswahl-Updates in gedrosselten Intervallen. - Sync-Engine: behandelt Wiederverbindung, erneutes Senden, Deduplizierung und Nachholen vom letzten bestätigten Sequenz. - Zustandsmanager: verwaltet bestätigten Zustand + ausstehende lokale Operationen. 4. Server-seitiges Design 4.1 WebSocket-Gateway - Aufrechterhalten persistenter bidirektionaler Verbindungen. - Authentifiziert Benutzer und autorisiert Board-Zugriff. - Leitet Nachrichten nach Board-/Session-ID weiter. - Kann horizontal skaliert werden; Sticky Sessions sind hilfreich, aber nicht erforderlich, wenn der Session-Zustand extern verwaltet wird. 4.2 Session-Koordinator - Verwaltet die Mitgliedschaft für jede Board-Session. - Veröffentlicht Join/Leave, Cursor-Präsenz und Auswahlzustand. - Verwendet Redis Pub/Sub oder einen Message-Bus, damit alle Gateway-Instanzen an Teilnehmer in demselben Board senden können. 4.3 Operationsprozessor - Empfängt Client-Operationen. - Validiert Schema, Board-Berechtigungen, Objekt-Existenz und Ratenbegrenzungen. - Weist eine Server-Sequenznummer pro Board zu. - Schreibt die Operation in ein append-only Event-Log. - Aktualisiert den In-Memory-Board-Zustand oder den Snapshot-Cache. - Sendet die kanonische Operation an alle verbundenen Benutzer. 4.4 Snapshot-Builder - Kompaktierung des Event-Logs in Board-Snapshots. - Auslösen der Snapshot-Erstellung alle N Operationen oder T Sekunden. - Beim Laden eines Boards rufen Clients den neuesten Snapshot + den Rest der Operationen nach der Snapshot-Version ab. 5. Kommunikationsprotokoll Verwendung von WebSocket für Echtzeit-Updates - Am besten geeignet für bidirektionale Kommunikation mit geringer Latenz. - Unterstützt häufige kleine Nachrichten: Striche, Transformationen, Cursor-Bewegungen, Acks. - Fallback auf HTTP-Polling nur bei Bedarf, aber WebSocket ist primär. Verwendung von HTTPS/REST (oder GraphQL) für nicht-Echtzeit-Flüsse - Login/Auth. - Abrufen von Board-Metadaten. - Abrufen des neuesten Snapshots/Verlaufs. - Erstellen von Board/Session. - Exportieren/Importieren. Beispiel für WebSocket-Nachrichtentypen - 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. Datenmodell und Persistenz 6.1 Logisches Board-Modell Board - board_id - owner/team - permissions - latest_seq - snapshot_version - created_at, updated_at Zeichenbares Objekt - object_id - type: stroke | textbox | rectangle | circle - version - z_index - style: color, width, fill, font, etc. - geometry: - stroke: Liste von Punkten oder komprimierten Pfadsegmenten - textbox: x, y, width, height, Textinhalt - shape: x, y, width, height, rotation - deleted flag oder Tombstone Operation/Ereignis - op_id (UUID für Idempotenz) - board_id - actor_id - client_id - client_op_seq - server_seq - timestamp - op_type - payload - base_version oder dependency metadata 6.2 Persistenzstrategie Event Sourcing + Snapshots - Jede Benutzeraktion als unveränderliche Operation in einem Event-Log speichern. - Periodisch materialisierte Snapshots speichern, um Boards schnell zu rekonstruieren. - Vorteile: - Einfaches Replay und Audit-Trail. - Einfachere Synchronisation und Wiederherstellung. - Gut geeignet für kollaborative Zeitachsen. Vorgeschlagene Speicheraufteilung - Metadaten in relationaler DB. - Event-Log in langlebigem, append-freundlichem Speicher (SQL-Tabelle, Kafka + DB-Sink oder NoSQL-Log-Speicher). - Snapshots im Objektspeicher oder Dokumentenspeicher. - Redis für ephemere Präsenz und heißen Board-Zustand. 7. Echtzeit-Synchronisationsstrategie 7.1 Operationsbasierte Synchronisation - Clients senden semantische Operationen, nicht vollständige Canvas-Bitmaps. - Beispiele: - Rechteck erstellen - Punkte zu Strich S hinzufügen - Text von Textfeld T aktualisieren - Form X um Delta verschieben - Objekt Y löschen - Dies hält die Bandbreite gering und macht Merges handhabbar. 7.2 Sequenzierungsmodell - Der Server weist pro Board eine monoton steigende server_seq zu. - Die kanonische Broadcast-Reihenfolge erfolgt nach server_seq. - Clients verfolgen last_seq_seen. - Bei Wiederverbindung fordert der Client fehlende Operationen seit last_seq_seen an. 7.3 Optimistisches UI - Der Client wendet seine eigene Operation sofort an. - Markiert sie als ausstehend, bis sie mit server_seq bestätigt wird. - Wenn der Server die Operation transformiert oder ablehnt, gleicht der Client durch Zurücksetzen ausstehender Operationen auf den kanonischen Zustand ab. 7.4 Batching und Drosselung - Freihandzeichnungen erzeugen viele Punkte, daher werden Punkte alle 20–50 ms oder nach N Punkten gebündelt. - Cursor-Updates sind ephemer; Drosselung auf ca. 20–30 Hz und keine Persistenz. - Dies reduziert die Last bei gleichzeitiger Beibehaltung des Echtzeit-Gefühls. 8. Konfliktlösung Da ein Whiteboard viele unabhängige Objekte enthält, verwenden Sie eine objektbasierte Konfliktbehandlung anstelle einer einzigen globalen Sperre. 8.1 Empfohlener Ansatz Verwenden Sie ein operationsbasiertes Modell mit pro-Objekt-Versionierung und einfachen OT/CRDT-inspirierten Regeln, abhängig vom Objekttyp. A. Unabhängige Objekterstellung - Gleichzeitige Erstellungen widersprechen sich niemals. - Jedes Objekt erhält eine global eindeutige object_id. B. Striche - Behandeln Sie jeden Strich während des Zeichnens als append-only. - Ein Strich gehört normalerweise seinem Ersteller, während er sich im aktiven Zeichenzustand befindet. - Andere Benutzer können denselben sich entwickelnden Strich normalerweise nicht ändern. - Sobald abgeschlossen, werden Bearbeitungen zu separaten Operationen (Verschieben, Stiländerung, Löschen). - Dies reduziert die Konfliktkomplexität erheblich. C. Formen und Textfelder - Verwenden Sie pro-Objekt-Versionen. - Updates enthalten base_version. - Wenn base_version mit der aktuellen Version übereinstimmt, direkt anwenden. - Andernfalls lösen Sie durch Feld-Level-Merge, wenn möglich: - Positions- und Größenänderungen: Last-Writer-Wins oder Transformationskomposition, wenn Operationen kommutativ sind. - Stiländerungen an verschiedenen Feldern können zusammengeführt werden. - Textinhalt: Verwenden Sie einen Text-CRDT/OT, wenn gleichzeitiges Bearbeiten von Text im selben Textfeld eine erforderliche Erfahrung ist. - Wenn reiche gleichzeitige Textbearbeitung nicht zentral ist, vereinfachen Sie, indem Sie eine aktive Editor-Sperre pro Textfeld zulassen. D. Löschen vs. Aktualisieren - Löschen hat Vorrang vor veralteten Updates, es sei denn, das Update hat eine spätere server_seq und das Objekt unterstützt Undelete/Versionswiederherstellung. - Halten Sie Tombstones kurz, damit späte Operationen sicher identifiziert und ignoriert werden können. 8.2 Praktische Konfliktrichtlinie für dieses System Für ein Whiteboard mittlerer Komplexität ist eine pragmatische Richtlinie: - Board-weite Ordnung nach server_seq. - Objekt-basierte Versionsprüfungen. - Last-Writer-Wins für Form-/Textbox-Transformationen und -Stile bei Kollisionen. - Soft Lock oder Single-Editor-Lease für aktive Textbox-Inhaltsbearbeitung. - Append-only Stroke-Erstellung mit Ersteller-Besitz während des Zeichnens. Dies ist einfacher als vollständige Board-OT und funktioniert gut für Whiteboards, bei denen die meisten Bearbeitungen unterschiedliche Objekte betreffen. 9. Skalierung für 50 gleichzeitige Benutzer pro Board Warum dies machbar ist - 50 Benutzer sind moderat, wenn Nachrichten kompakt und ephemerer Verkehr gedrosselt sind. Techniken - Ein Session-Shard pro Board im Speicher/Cache für schnelles Fan-out. - WebSocket-Fan-out über Pub/Sub. - Stapeln von Strichpunkten. - Komprimieren von Nachrichten mit permessage-deflate, wenn nützlich. - Vermeiden Sie das Speichern von Cursor-/Präsenzrauschen. - Snapshots häufig genug erstellen, um lange Wiedergabezeiten zu vermeiden. Kapazitätsüberlegungen - Heißer Board-Zustand im Speicher: aktuelle Objektkarte, neueste Sequenz, Teilnehmerliste. - Broadcast-Pfad sollte O(Benutzer im Board) sein, was für 50 Benutzer in Ordnung ist. - Wenn Sessions später größer werden, fügen Sie regionale Edge-Gateways hinzu und partitionieren Sie Sessions über Kollaborationsarbeiter. 10. Fehlerbehandlung und Zuverlässigkeit - Jede Operation hat eine op_id für die Deduplizierung bei Wiederholungsversuchen. - Client stellt mit last_seq_seen wieder eine Verbindung her und erhält verpasste Operationen. - Wenn die Lücke zu groß ist oder der Snapshot abgelaufen ist, weist der Server eine vollständige Resynchronisation vom neuesten Snapshot an. - Event-Log bietet Dauerhaftigkeit, wenn der Kollaborationsarbeiter abstürzt. - Präsenzzustand ist ephemer und wird bei Wiederverbindung neu aufgebaut. 11. Latenzstrategie, um unter 500 ms zu bleiben - WebSocket-Persistenzverbindungen vermeiden die Kosten für die Einrichtungsanforderung. - Client-seitiges optimistisches Rendering bietet eine nahezu sofortige lokale Reaktion. - Kollaborationsserver halten den heißen Session-Zustand im Speicher. - Regionale Bereitstellung platziert Benutzer in der Nähe des nächstgelegenen Gateways. - Batching gleicht Durchsatz und Verzögerung aus; Verwenden Sie kleine Flush-Intervalle für Striche. - Broadcast aus Speicher/Cache, anstatt die Datenbank bei jeder Aktualisierung erneut zu lesen. 12. Sicherheit und Zugriffskontrolle - Authentifizierte WebSocket-Aufrüstung mittels Token/Cookie. - ACL auf Board-Ebene: Rollen als Besitzer/Editor/Zuschauer. - Server validiert jede Operation gegen Berechtigungen. - Ratenbegrenzung pro Client zur Verhinderung von Missbrauch oder versehentlichen Fluten. 13. Beispiel für einen End-to-End-Fluss - Benutzer öffnet ein Board über HTTPS und ruft den neuesten Snapshot + die restlichen Operationen ab. - Client stellt eine WebSocket-Verbindung her und sendet join_board mit last_seq_seen. - Benutzer zeichnet eine Linie; der Client rendert sofort und sendet gebündelte append_stroke_points Operationen. - Der Server validiert, weist server_seq zu, fügt das Event-Log hinzu, aktualisiert den Session-Zustand und sendet an alle Benutzer. - Andere Clients empfangen die Operationen und rendern den Strich inkrementell. - Wenn ein Client die Verbindung trennt, stellt er sie wieder her und fordert die Operationen seit seiner letzten gesehenen Sequenz an. 14. Empfohlene endgültige Designentscheidung - Client: Local-First Canvas Renderer + optimierter Op-Puffer. - Server: WebSocket Gateways + Kollaborations-/Session-Dienst + append-only Op-Log + Snapshots. - Protokoll: WebSocket für Echtzeit-Operationen/Präsenz, HTTPS für Board-Laden und Admin-APIs. - Konsistenzmodell: Server-sortierte Operationen mit objektbasierter Versionierung. - Konfliktlösung: Append-only Striche, einfache Merge/LWW für Formen, optionaler Lock oder CRDT für Textbox-Inhalt. Dieses Design ist einfach zu erstellen, erfüllt die Anforderungen der nahezu Echtzeit-Kollaboration und skaliert gut für 50 gleichzeitige Benutzer pro Whiteboard, während Synchronisation und Konfliktbehandlung überschaubar bleiben.

# Entwurf eines Echtzeit-Kollaborations-Whiteboard-Systems ## Überblick über die High-Level-Architektur Das System besteht aus drei Hauptschichten: clientseitiges Rendering und Interaktion, Echtzeit-Kommunikationsinfrastruktur und serverseitige Zustandsverwaltung mit Persistenz. ## Schlüsselkomponenten ### Clientseitige Architektur 1. **Canvas-Rendering-Engine**: WebGL oder Canvas 2D API für effizientes Zeichnen und Rendern aller Whiteboard-Elemente 2. **Lokaler Zustandsmanager**: Verwaltet eine lokale Kopie des Canvas-Zustands für sofortiges visuelles Feedback 3. **Eingabeverarbeitung**: Erfasst Benutzereingaben (Maus-/Touch-Ereignisse) und wandelt sie in Zeichenoperationen um 4. **WebSocket-Client**: Stellt eine persistente bidirektionale Verbindung zum Server her 5. **Konfliktlösungs-Schicht**: Wendet Operationale Transformation oder CRDT-Logik lokal an, bevor sie an den Server gesendet werden 6. **Undo/Redo-Manager**: Verwaltet den Operationsverlauf für lokale Undo/Redo-Funktionalität ### Serverseitige Architektur 1. **WebSocket-Server**: Verarbeitet mehrere gleichzeitige Client-Verbindungen mit Node.js und Socket.io oder nativem WebSocket 2. **Sitzungsmanager**: Verwaltet aktive Whiteboard-Sitzungen und Benutzerpräsenzinformationen 3. **Operationsprotokoll**: Speichert alle Zeichenoperationen in der Reihenfolge ihres Eingangs 4. **Zustandsabgleich-Engine**: Wendet Operationen auf den kanonischen Canvas-Zustand an und verteilt Updates 5. **Konfliktlösungsdienst**: Implementiert operationale Transformation oder CRDT zur Behandlung gleichzeitiger Bearbeitungen 6. **Persistenz-Schicht**: Speichert Whiteboard-Schnappschüsse und Operationsprotokolle in einer Datenbank 7. **Cache-Schicht**: Redis für schnellen Zugriff auf aktive Sitzungszustände ## Kommunikationsprotokoll **Protokoll**: WebSocket mit JSON-Nachrichtenformat **Nachrichtentypen**: - `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} (zur Wahrnehmung) - `ack`: {operationId} (Bestätigung des Eingangs) - `sync_request`: {userId, lastKnownVersion} - `full_state`: {version, elements, operations} **Latenzoptimierung**: - Binäres Protokoll (MessagePack) für kleinere Nutzlastgrößen verwenden - Nachrichten-Batching implementieren: Operationen ca. 50 ms sammeln, bevor sie gesendet werden - Delta-Kompression für Zustandsaktualisierungen verwenden - Ziel: <500 ms End-to-End-Latenz durch optimierte Serververarbeitung und CDN-verteilte WebSocket-Server ## Datenmodellierung **Canvas-Element-Schema**: ``` Element { id: UUID, type: 'line' | 'rectangle' | 'circle' | 'text', userId: string, createdAt: timestamp, updatedAt: timestamp, version: number, data: { // Für Linien: Punkte-Array [{x, y}, ...] // Für Formen: {x, y, width, height, rotation} // Für Text: {x, y, content, fontSize, fontFamily, color} }, style: {color, strokeWidth, opacity, ...} } ``` **Operations-Schema**: ``` Operation { id: UUID, sessionId: string, userId: string, type: 'create' | 'update' | 'delete', elementId: string, timestamp: number, lamportClock: number, payload: {...}, clientId: string } ``` ## Echtzeit-Synchronisationsstrategie ### Operationale Transformations (OT)-Ansatz 1. **Operationsreihenfolge**: Lamport-Uhren kombiniert mit userId verwenden, um eine totale Reihenfolge von gleichzeitigen Operationen zu etablieren 2. **Transformationsfunktion**: Wenn zwei Operationen kollidieren, transformieren Sie sie gegeneinander: - Wenn Benutzer A eine Linie zeichnet und Benutzer B gleichzeitig Text hinzufügt, werden beide Operationen beibehalten - Transformation stellt sicher, dass der endgültige Zustand auf allen Clients konsistent ist 3. **Server als Autorität**: Der Server empfängt Operationen, weist Lamport-Uhren-Werte zu, transformiert sie gegen gleichzeitige Operationen und verteilt die kanonische Version 4. **Clientseitige Vorhersage**: Clients wenden Operationen optimistisch mit temporären IDs an und gleichen sie dann ab, wenn der Server dies bestätigt ### Konfliktlösungsverfahren 1. **Erkennung**: Server identifiziert gleichzeitige Operationen (innerhalb desselben Zeitfensters empfangen) 2. **Transformation**: OT-Transformationsregeln anwenden: - Positionsbasierte Konflikte (zwei Formen am selben Ort): Beide beibehalten, Positionen leicht anpassen - Textkonflikte: Einfügungsreihenfolge basierend auf Lamport-Uhr beibehalten - Löschkonflikte: Last-Write-Wins mit Timestamp als Tiebreaker 3. **Verteilung**: Transformierte Operationen mit kanonischer Versionsnummer an alle Clients senden 4. **Client-Abgleich**: Clients vergleichen den lokalen Zustand mit der Serverversion; bei Abweichungen eine vollständige Zustands-Synchronisation anfordern ### Umgang mit 50 gleichzeitigen Benutzern 1. **Horizontale Skalierung**: Mehrere WebSocket-Server hinter einem Load Balancer bereitstellen 2. **Sitzungs-Sharding**: Jede Whiteboard-Sitzung einem bestimmten Server-Instanz zuweisen 3. **Redis Pub/Sub**: Für die serverübergreifende Kommunikation, wenn eine Sitzung mehrere Server umfasst 4. **Operations-Batching**: Operationen vor der Verarbeitung in Stapel von 10-20 gruppieren 5. **Lazy Evaluation**: Nur den sichtbaren Canvas-Bereich rendern; verzögertes Rendern für außerhalb des Bildschirms liegende Bereiche 6. **Verbindungspooling**: Datenbankverbindungen für Persistenzschreibvorgänge wiederverwenden ## Persistenzstrategie 1. **Operationsprotokoll**: Nur-Anfügen-Protokoll aller Operationen, das in der Datenbank gespeichert wird - Ermöglicht die vollständige Rekonstruktion jedes historischen Zustands - Unterstützt Audit-Trail und Undo-Funktionalität 2. **Periodische Schnappschüsse**: Alle 1000 Operationen oder alle 5 Minuten wird ein Canvas-Schnappschuss erstellt - Reduziert die Wiederherstellungszeit bei Serverneustart - Wird mit Versionsnummer in der Datenbank gespeichert 3. **Asynchrone Schreibvorgänge**: Operationen werden in der Datenbank persistiert, nachdem sie an die Clients verteilt wurden - Verhindert, dass die Persistenz Echtzeit-Updates blockiert - Write-Ahead Logging für Ausfallsicherheit verwenden 4. **Datenstruktur**: In einer Dokumentendatenbank (MongoDB) oder einer Zeitreihendatenbank für effiziente Abfragen speichern ## Skalierbarkeitsüberlegungen - **Speicher**: Aktive Sitzungen in Redis cachen; inaktive Sitzungen nach 30 Minuten auslagern - **Netzwerk**: Nachrichtenkomprimierung implementieren; CDN für statische Assets verwenden - **Datenbank**: Nach sessionId und Timestamp für schnelle Abfragen indizieren; alte Sitzungen archivieren - **Überwachung**: Operationslatenz, Verbindungsanzahl und Konfliktrate verfolgen ## Sicherheitsmaßnahmen - Benutzer authentifizieren, bevor der Sitzungszugriff gewährt wird - Alle Operationen serverseitig validieren - Ratenbegrenzung pro Benutzer implementieren (max. 100 Operationen/Sekunde) - Daten während der Übertragung (WSS) und im Ruhezustand verschlüsseln - Zugriffskontrolle für Sitzungsberechtigungen implementieren Dieses Design bietet ein Gleichgewicht zwischen Echtzeit-Reaktionsfähigkeit, Konsistenz und Skalierbarkeit und ermöglicht eine reibungslose Zusammenarbeit für bis zu 50 gleichzeitige Benutzer mit einer Latenz von unter 500 ms.