Concevoir un tableau blanc collaboratif en temps réel

Plan de haut niveau pour un tableau blanc collaboratif en temps réel 1. Objectifs et hypothèses - Prise en charge de plus de 50 utilisateurs simultanés sur un même tableau. - Visibilité des mises à jour de bout en bout en moins de 500 ms. - Opérations : traits à main levée, zones de texte, rectangles/cercles, déplacement/redimensionnement/suppression. - Réactivité forte tout en maintenant la cohérence éventuelle des vues de tous les utilisateurs. - Privilégier la disponibilité et la faible latence par rapport à un ordre global strict. 2. Architecture de haut niveau Applications clientes - Interface utilisateur de tableau blanc Web/mobile. - Moteur de rendu local utilisant Canvas/WebGL/SVG. - Couche de capture d'entrées pour les événements pointeur/souris/tactiles. - Tampon d'opérations local et application optimiste. - Module de synchronisation en temps réel via WebSocket. - Stockage d'instantanés/cache pour l'état actuel du tableau. Couche API et session - API HTTPS pour l'authentification, la découverte de tableaux, les autorisations, le chargement de l'instantané initial du tableau, l'exportation du tableau. - Passerelle WebSocket pour le trafic de sessions en temps réel. Backend de collaboration - Service coordinateur de session : suit les utilisateurs connectés par tableau, la présence, les curseurs et le routage. - Processeur d'opérations : valide les opérations, attribue les métadonnées de séquençage, persiste le journal des événements, diffuse aux participants. - Couche de résolution des conflits : applique les règles d'ordre/d'idempotence et les politiques de fusion au niveau de l'objet. Couche de stockage - Journal persistant des événements pour les opérations du tableau. - Stockage périodique d'instantanés du tableau pour un chargement rapide. - Base de données de métadonnées pour les utilisateurs, les tableaux, les ACL, les informations de session. - Cache optionnel en mémoire (par ex. Redis) pour les sessions actives, la présence, l'état éphémère des curseurs. 3. Conception côté client Modèle de rendu - Représenter le tableau comme un graphe de scène d'objets : - Trait - Zone de texte - Forme - Chaque objet a un object_id stable, un z_index, un style, une transformation, created_by, des horodatages/version. - Pour le dessin à main levée, le client échantillonne les points et les lisse localement pour un retour immédiat. Comportement local en premier - Les actions de l'utilisateur sont appliquées immédiatement sur le client pour une faible latence perçue. - Le client envoie les opérations de manière asynchrone au serveur. - Les accusés de réception du serveur réconcilient les opérations locales en attente avec l'ordre canonique. Modules clients - Module de présence/curseur : envoie des mises à jour légères de curseur/sélection à intervalles limités. - Moteur de synchronisation : gère la reconnexion, le renvoi, la déduplication et le rattrapage à partir de la dernière séquence acquittée. - Gestionnaire d'état : maintient l'état confirmé + les opérations locales en attente. 4. Conception côté serveur 4.1 Passerelle WebSocket - Maintient des connexions bidirectionnelles persistantes. - Authentifie l'utilisateur et autorise l'accès au tableau. - Route les messages par ID de tableau/session. - Peut être mis à l'échelle horizontalement ; les sessions collantes aident mais ne sont pas requises si l'état de la session est externalisé. 4.2 Coordinateur de session - Maintient l'adhésion pour chaque session de tableau. - Publie les événements de connexion/déconnexion, de présence du curseur et d'état de sélection. - Utilise Redis pub/sub ou un bus de messages afin que toutes les instances de passerelle puissent diffuser aux participants du même tableau. 4.3 Processeur d'opérations - Reçoit les opérations du client. - Valide le schéma, les autorisations du tableau, l'existence de l'objet et les limites de débit. - Attribue un numéro de séquence serveur par tableau. - Écrit l'opération dans le journal des événements immuable. - Met à jour l'état du tableau en mémoire ou le cache d'instantanés. - Diffuse l'opération canonique à tous les utilisateurs connectés. 4.4 Générateur d'instantanés - Compacte périodiquement le journal des événements en instantanés de tableau. - Déclenche la création d'instantanés toutes les N opérations ou T secondes. - Lors du chargement d'un tableau, les clients récupèrent le dernier instantané + la queue des opérations après la version de l'instantané. 5. Protocole de communication Utiliser WebSocket pour les mises à jour en temps réel - Le plus adapté à la communication bidirectionnelle à faible latence. - Prend en charge les petits messages fréquents : traits, transformations, mouvement du curseur, accusés de réception. - Retour au sondage HTTP uniquement si nécessaire, mais WebSocket est le principal. Utiliser HTTPS/REST (ou GraphQL) pour les flux non temps réel - Connexion/authentification. - Récupération des métadonnées du tableau. - Récupération du dernier instantané/historique. - Création de tableau/session. - Exportation/importation. Exemples de types de messages WebSocket - 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. Modèle de données et persistance 6.1 Modèle logique du tableau Tableau - board_id - owner/team - permissions - latest_seq - snapshot_version - created_at, updated_at Objet dessinable - object_id - type: stroke | textbox | rectangle | circle - version - z_index - style: color, width, fill, font, etc. - geometry: - stroke: liste de points ou segments de chemin compressés - textbox: x, y, width, height, contenu texte - shape: x, y, width, height, rotation - flag deleted ou tombstone Opération/événement - op_id (UUID pour l'idempotence) - board_id - actor_id - client_id - client_op_seq - server_seq - timestamp - op_type - payload - base_version ou métadonnées de dépendance 6.2 Stratégie de persistance Événementiel + instantanés - Persister chaque action utilisateur comme une opération immuable dans un journal d'événements. - Stocker des instantanés matérialisés périodiques pour une reconstruction rapide du tableau. - Avantages : - Reprise et piste d'audit faciles. - Synchronisation et récupération simplifiées. - Convient bien aux chronologies collaboratives. Séparation de stockage suggérée - Métadonnées dans une base de données relationnelle. - Journal des événements dans un stockage immuable et append-friendly (table SQL, Kafka + sink DB, ou stockage de log NoSQL). - Instantanés dans un stockage d'objets ou un stockage de documents. - Redis pour la présence éphémère et l'état des tableaux actifs. 7. Stratégie de synchronisation en temps réel 7.1 Synchronisation basée sur les opérations - Les clients envoient des opérations sémantiques, pas des bitmaps de toilettes complètes. - Exemples : - Créer un rectangle - Ajouter des points au trait S - Mettre à jour le texte de la zone de texte T - Déplacer la forme X par delta - Supprimer l'objet Y - Cela maintient la bande passante faible et rend les fusions gérables. 7.2 Modèle de séquençage - Le serveur attribue un server_seq monotone et croissant par tableau. - L'ordre de diffusion canonique est par server_seq. - Les clients suivent le last_seq_seen. - Lors de la reconnexion, le client demande les opérations manquantes depuis last_seq_seen. 7.3 Interface utilisateur optimiste - Le client applique sa propre opération immédiatement. - La marque comme en attente jusqu'à ce qu'elle soit acquittée avec server_seq. - Si le serveur transforme/rejette l'opération, le client se réconcilie en rebasant les opérations en attente sur l'état canonique. 7.4 Batching et limitation - Le dessin à main levée génère de nombreux points, donc regroupez les points toutes les 20–50 ms ou après N points. - Les mises à jour du curseur sont éphémères ; limitez à environ 20–30 Hz et ne les conservez pas. - Cela réduit la charge tout en préservant la sensation de temps réel. 8. Résolution des conflits Comme un tableau blanc contient de nombreux objets indépendants, utilisez une gestion des conflits au niveau de l'objet plutôt qu'un seul verrou global. 8.1 Approche recommandée Utilisez un modèle basé sur les opérations avec versionnement par objet et des règles simples inspirées de OT/CRDT en fonction du type d'objet. A. Création d'objets indépendants - Les créations concurrentes ne créent jamais de conflit. - Chaque objet obtient un object_id unique global. B. Traits - Traitez chaque trait comme append-only pendant le dessin. - Un trait est généralement détenu par son créateur pendant l'état de dessin actif. - D'autres utilisateurs ne peuvent généralement pas modifier le même trait en cours. - Une fois terminé, les modifications deviennent des opérations distinctes (déplacement, changement de style, suppression). - Cela réduit considérablement la complexité des conflits. C. Formes et zones de texte - Utilisez des versions par objet. - Les mises à jour incluent la base_version. - Si base_version correspond à la version actuelle, appliquez directement. - Sinon, résolvez par fusion au niveau du champ lorsque c'est possible : - Éditions de position et de taille : last-writer-wins ou composition de transformation si les opérations sont commutatives. - Les changements de style sur différents champs peuvent être fusionnés. - Contenu texte : utilisez un CRDT/OT de texte si l'édition de texte simultanée dans la même zone de texte est une expérience requise. - Si l'édition de texte simultanée riche n'est pas essentielle, simplifiez en autorisant un verrou d'éditeur actif par zone de texte. D. Suppression vs mise à jour - La suppression l'emporte sur les mises à jour obsolètes, sauf si la mise à jour a un server_seq plus récent et que l'objet prend en charge la restauration/version. - Conservez les tombstones brièvement afin que les opérations tardives puissent être identifiées et ignorées en toute sécurité. 8.2 Politique de conflit pratique pour ce système Pour un tableau blanc de complexité moyenne, une politique pragmatique est : - Ordre au niveau du tableau par server_seq. - Vérifications de version au niveau de l'objet. - Last-writer-wins pour les transformations et styles de formes/zones de texte si les modifications entrent en collision. - Verrouillage souple ou bail d'éditeur unique pour l'édition de contenu de zone de texte active. - Création de traits append-only avec propriété du créateur pendant le dessin. Ceci est plus simple que le OT complet de tableau et fonctionne bien pour les tableaux blancs, où la plupart des modifications ciblent différents objets. 9. Gestion de la montée en charge pour 50 utilisateurs simultanés par tableau Pourquoi c'est faisable - 50 utilisateurs est modéré si les messages sont compacts et le trafic éphémère est limité. Techniques - Un shard de session par tableau en mémoire/cache pour un fan-out rapide. - Fan-out WebSocket via pub/sub. - Regroupement des points de trait. - Compression des messages avec permessage-deflate si utile. - Éviter la persistance du bruit de curseur/présence. - Instantanés suffisamment fréquents pour éviter des temps de relecture longs. Considérations de capacité - État de session actif en mémoire : carte d'objets actuelle, dernier seq, liste des participants. - Le chemin de diffusion doit être O(utilisateurs dans le tableau), ce qui est correct pour 50 utilisateurs. - Si les sessions augmentent plus tard, ajoutez des passerelles périphériques régionales et partitionnez les sessions entre les travailleurs de collaboration. 10. Gestion des pannes et fiabilité - Chaque opération a un op_id pour la déduplication lors des nouvelles tentatives. - Le client se reconnecte avec last_seq_seen et reçoit les opérations manquées. - Si l'écart est trop grand ou l'instantané expiré, le serveur demande une resynchronisation complète à partir du dernier instantané. - Le journal des événements assure la durabilité en cas de crash d'un travailleur de collaboration. - L'état de présence est éphémère et reconstruit lors de la reconnexion. 11. Stratégie de latence pour rester sous 500 ms - Les connexions persistantes WebSocket évitent le coût de configuration de la requête. - Le rendu optimiste côté client donne une réponse locale quasi instantanée. - Les serveurs de collaboration maintiennent l'état de session actif en mémoire. - Le déploiement régional place les utilisateurs à proximité de la passerelle la plus proche. - Le regroupement équilibre débit et délai ; utilisez de petits intervalles de vidage pour les traits. - Diffusion à partir de la mémoire/du cache plutôt que de relire la base de données à chaque mise à jour. 12. Sécurité et contrôle d'accès - Mise à niveau WebSocket authentifiée à l'aide d'un jeton/cookie. - ACL au niveau du tableau : rôles propriétaire/éditeur/lecteur. - Le serveur valide chaque opération par rapport aux autorisations. - Limitation du débit par client pour éviter les abus ou les inondations accidentelles. 13. Exemple de flux de bout en bout - L'utilisateur ouvre un tableau via HTTPS et récupère le dernier instantané + les opérations de queue. - Le client établit une connexion WebSocket et envoie join_board avec last_seq_seen. - L'utilisateur dessine une ligne ; le client la rend instantanément et envoie des opérations append_stroke_points regroupées. - Le serveur valide, attribue server_seq, ajoute au journal des événements, met à jour l'état de la session, diffuse à tous les utilisateurs. - Les autres clients reçoivent les opérations et rendent le trait progressivement. - Si un client se déconnecte, il se reconnecte et demande les opérations depuis sa dernière séquence vue. 14. Choix de conception final recommandé - Client : moteur de rendu de toile basé sur le local d'abord + tampon d'opérations optimiste. - Serveur : passerelles WebSocket + service de collaboration/session + journal d'opérations immuable + instantanés. - Protocole : WebSocket pour les opérations/présence en temps réel, HTTPS pour le chargement du tableau et les API d'administration. - Modèle de cohérence : opérations ordonnées par serveur avec versionnement au niveau de l'objet. - Résolution des conflits : traits append-only, fusion simple/LWW pour les formes, verrouillage optionnel ou CRDT pour le contenu des zones de texte. Cette conception est simple à construire, répond aux besoins de collaboration quasi temps réel, et s'adapte confortablement à 50 utilisateurs simultanés par tableau tout en maintenant la synchronisation et la gestion des conflits gérables.

# Conception d'un Système de Tableau Blanc Collaboratif en Temps Réel ## Vue d'ensemble de l'Architecture de Haut Niveau Le système se compose de trois couches principales : le rendu côté client et l'interaction, l'infrastructure de communication en temps réel et la gestion d'état côté serveur avec persistance. ## Composants Clés ### Architecture Côté Client 1. **Moteur de Rendu de Canevas** : API WebGL ou Canvas 2D pour un dessin et un rendu efficaces de tous les éléments du tableau blanc 2. **Gestionnaire d'État Local** : Maintient une copie locale de l'état du canevas pour un retour visuel immédiat 3. **Gestionnaire d'Entrées** : Capture les interactions utilisateur (événements souris/tactiles) et les convertit en opérations de dessin 4. **Client WebSocket** : Établit une connexion bidirectionnelle persistante avec le serveur 5. **Couche de Résolution de Conflits** : Applique la transformation opérationnelle ou la logique CRDT localement avant l'envoi au serveur 6. **Gestionnaire d'Annulation/Rétablissement** : Maintient l'historique des opérations pour la fonctionnalité d'annulation/rétablissement locale ### Architecture Côté Serveur 1. **Serveur WebSocket** : Gère plusieurs connexions client simultanées à l'aide de Node.js avec Socket.io ou WebSocket natif 2. **Gestionnaire de Sessions** : Maintient les sessions de tableau blanc actives et les informations de présence des utilisateurs 3. **Journal des Opérations** : Stocke toutes les opérations de dessin dans l'ordre de réception 4. **Moteur de Réconciliation d'État** : Applique les opérations à l'état canonique du canevas et diffuse les mises à jour 5. **Service de Résolution de Conflits** : Implémente la transformation opérationnelle ou CRDT pour gérer les modifications concurrentes 6. **Couche de Persistance** : Stocke les instantanés du tableau blanc et les journaux d'opérations dans la base de données 7. **Couche de Cache** : Redis pour un accès rapide aux états de session actifs ## Protocole de Communication **Protocole** : WebSocket avec format de message JSON **Types de Messages** : - `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} (pour la conscience) - `ack` : {operationId} (accusé de réception) - `sync_request` : {userId, lastKnownVersion} - `full_state` : {version, elements, operations} **Optimisation de la Latence** : - Utiliser un protocole binaire (MessagePack) pour des tailles de charge utiles plus petites - Implémenter le regroupement de messages : collecter les opérations pendant 50 ms avant l'envoi - Utiliser la compression delta pour les mises à jour d'état - Objectif : latence de bout en bout <500 ms grâce à un traitement serveur optimisé et des serveurs WebSocket distribués par CDN ## Modélisation des Données **Schéma d'Élément de Canevas** : ``` Element { id: UUID, type: 'line' | 'rectangle' | 'circle' | 'text', userId: string, createdAt: timestamp, updatedAt: timestamp, version: number, data: { // Pour les lignes : tableau de points [{x, y}, ...] // Pour les formes : {x, y, width, height, rotation} // Pour le texte : {x, y, content, fontSize, fontFamily, color} }, style: {color, strokeWidth, opacity, ...} } ``` **Schéma d'Opération** : ``` Operation { id: UUID, sessionId: string, userId: string, type: 'create' | 'update' | 'delete', elementId: string, timestamp: number, lamportClock: number, payload: {...}, clientId: string } ``` ## Stratégie de Synchronisation en Temps Réel ### Approche de Transformation Opérationnelle (OT) 1. **Ordre des Opérations** : Utiliser les horloges Lamport combinées à l'identifiant utilisateur pour établir un ordre total des opérations concurrentes 2. **Fonction de Transformation** : Lorsque deux opérations entrent en conflit, les transformer l'une par rapport à l'autre : - Si l'utilisateur A dessine une ligne et que l'utilisateur B ajoute du texte au même moment, les deux opérations sont préservées - La transformation garantit que l'état final est cohérent sur tous les clients 3. **Serveur comme Autorité** : Le serveur reçoit les opérations, attribue des valeurs d'horloge Lamport, transforme les opérations concurrentes et diffuse la version canonique 4. **Prédiction Côté Client** : Les clients appliquent les opérations de manière optimiste avec des identifiants temporaires, puis se réconcilient lorsque le serveur confirme ### Processus de Résolution de Conflits 1. **Détection** : Le serveur identifie les opérations concurrentes (reçues dans la même fenêtre temporelle) 2. **Transformation** : Appliquer les règles de transformation OT : - Conflits basés sur la position (deux formes au même endroit) : préserver les deux, ajuster légèrement les positions - Conflits de texte : maintenir l'ordre d'insertion basé sur l'horloge Lamport - Conflits de suppression : la dernière écriture gagne avec un égaliseur basé sur le timestamp 3. **Diffusion** : Envoyer les opérations transformées à tous les clients avec un numéro de version canonique 4. **Réconciliation Côté Client** : Les clients comparent leur version locale à la version du serveur ; si elle diffère, demandent une synchronisation complète de l'état ### Gestion de 50 Utilisateurs Concurrents 1. **Mise à l'Échelle Horizontale** : Déployer plusieurs serveurs WebSocket derrière un répartiteur de charge 2. **Partitionnement des Sessions** : Chaque session de tableau blanc est assignée à une instance de serveur spécifique 3. **Redis Pub/Sub** : Pour la communication inter-serveurs si une session s'étend sur plusieurs serveurs 4. **Regroupement des Opérations** : Grouper les opérations par lots de 10 à 20 avant le traitement 5. **Évaluation Paresseuse** : Rendre uniquement la zone visible du canevas ; différer le rendu hors écran 6. **Pool de Connexions** : Réutiliser les connexions à la base de données pour les écritures de persistance ## Stratégie de Persistance 1. **Journal des Opérations** : Journal d'ajout uniquement de toutes les opérations stockées dans la base de données - Permet la reconstruction complète de tout état historique - Prend en charge la piste d'audit et la fonctionnalité d'annulation 2. **Instantanés Périodiques** : Toutes les 1000 opérations ou toutes les 5 minutes, créer un instantané du canevas - Réduit le temps de récupération lors du redémarrage du serveur - Stocké dans la base de données avec un numéro de version 3. **Écritures Asynchrones** : Persister les opérations dans la base de données après leur diffusion aux clients - Empêche la persistance de bloquer les mises à jour en temps réel - Utiliser le journalisation d'écriture anticipée pour la durabilité 4. **Structure de Données** : Stocker dans une base de données de documents (MongoDB) ou une base de données de séries temporelles pour des requêtes efficaces ## Considérations de Mise à l'Échelle - **Mémoire** : Mettre en cache les sessions actives dans Redis ; expulser les sessions inactives après 30 minutes - **Réseau** : Implémenter la compression des messages ; utiliser le CDN pour les actifs statiques - **Base de Données** : Indexer par sessionId et timestamp pour des requêtes rapides ; archiver les anciennes sessions - **Surveillance** : Suivre la latence des opérations, le nombre de connexions et le taux de conflits ## Mesures de Sécurité - Authentifier les utilisateurs avant d'autoriser l'accès à la session - Valider toutes les opérations côté serveur - Implémenter la limitation de débit par utilisateur (max 100 opérations/seconde) - Chiffrer les données en transit (WSS) et au repos - Implémenter le contrôle d'accès pour les autorisations de session Cette conception équilibre la réactivité en temps réel avec la cohérence et la scalabilité, permettant une collaboration fluide pour jusqu'à 50 utilisateurs simultanés avec une latence inférieure à 500 ms.