Concevoir un système de tableau blanc collaboratif en temps réel

# Tableau blanc collaboratif en temps réel — Conception du système ## 1. Architecture de haut niveau Composants et flux de requêtes/données : ``` ┌──────────────┐ Clients Web/Mobile/Desktop │ Clients │ (Rendu du canevas, réplique CRDT locale, Clients ─────► │ (100/tableau) │ client WebSocket, tampon hors ligne) └──────┬───────┘ │ HTTPS (REST) + WSS (WebSocket) ┌──────▼───────┐ │ CDN │ (ressources statiques, images exportées) └──────┬───────┘ ┌──────▼───────────────┐ │ Équilibreur de charge │ (L7, terminaison TLS, │ global + passerelle │ authentification, limitation │ API │ de débit) └───┬───────────────┬───┘ Trafic REST │ │ Mise à niveau WS (collant par sessionId) ┌──────────────▼──┐ ┌─────▼───────────────┐ │ Services App │ │ Serveurs Collab │ │ sans état │ │ Temps Réel (WS) │ │ (auth, CRUD │ │ - maintiennent en │ │ tableau, │ │ mémoire l'état │ │ partage, │ │ du tableau │ │ exports) │ │ - fusionnent ops (CRDT)│ └───┬────────┬─────┘ │ - diffusent des deltas │ │ │ └───┬───────────┬──────┘ ┌───────▼──┐ ┌───▼─────┐ ┌────▼────┐ ┌───▼────────┐ │ DB Métadonnées │ │ Stockage Objet/ │ │ Redis │ │ Routage de │ │(Postgres)│ │ Blob (S3) │ │ Pub/Sub │ │ Session │ └──────────┘ └─────────┘ │+Présence│ │(Hachage │ │ └─────────┘ │ cohérent) │ ┌───────▼─────────────┐ ┌─────────────────────────────┐ │ Stockage Docs/Ops │ │ Travailleurs Asynchrones (file│ │ (DynamoDB/Cassandra: │◄──│ d'attente Kafka) │ │ log ops + snapshots) │ │ - création de snapshots │ └─────────────────────┘ │ - génération miniatures/exports│ │ - analyses │ └─────────────────────────────┘ ``` **Résumé des interactions :** Les clients s'authentifient via la passerelle API (REST), puis ouvrent une connexion WebSocket persistante vers un serveur de collaboration en temps réel. La passerelle utilise le hachage cohérent sur `sessionId` afin que tous les participants d'un tableau atterrissent sur le même serveur (ou un petit ensemble de répliques), maintenant l'état actif faisant autorité en un seul endroit. Les services d'application gèrent le CRUD non temps réel (création de tableaux, partage, listage, exports). Redis Pub/Sub relie les serveurs en temps réel afin que, si les participants sont répartis sur plusieurs instances, les opérations se propagent toujours. Des travailleurs asynchrones persistent périodiquement des instantanés et le journal des opérations dans un stockage durable. ## 2. Communication en temps réel - **Protocole :** WebSocket (WSS) pour une messagerie bidirectionnelle, full-duplex et à faible latence. Se rabat sur le long-polling HTTP via une bibliothèque comme Socket.IO pour les réseaux restrictifs. Les canaux de données WebRTC sont envisagés pour le partage de curseurs/présence en peer-to-peer, mais un modèle relayé par serveur est choisi pour la simplicité et la fiabilité. - **Modèle de message :** Les clients envoient de petites **opérations/deltas** (par exemple, `{type:'stroke_add', objId, points, color}`, `{type:'obj_move', objId, dx, dy}`) plutôt que l'état complet du tableau. Le serveur valide, attribue une séquence/version, fusionne et diffuse le delta à tous les autres membres de la session. - **Diffusion (Fan-out) :** Chaque serveur en temps réel conserve l'ensemble des connexions par tableau en mémoire et diffuse directement les deltas. Pour les tableaux dont les membres s'étendent sur plusieurs serveurs, le serveur d'origine publie l'opération dans un canal Redis Pub/Sub indexé par `sessionId` ; les serveurs abonnés retransmettent aux connexions locales. - **Présence et curseurs :** Les données à haute fréquence et de faible valeur (positions de curseur en direct, sélections) sont limitées en débit (environ 30–60 ms) et envoyées au mieux, jamais persistées. - **Cible de latence (<200 ms) :** Atteinte via des clusters de collaboration en temps réel régionaux, un routage collant (pas de sauts inter-régionaux), des charges utiles binaires minuscules/JSON compactes et un rendu local optimiste (le client applique sa propre opération immédiatement, puis se réconcilie). ## 3. Modèle de données **Métadonnées du tableau (Postgres — relationnel, transactionnel) :** - `boards(board_id, owner_id, title, created_at, updated_at, latest_snapshot_id)` - `users(user_id, name, email, ...)` - `board_permissions(board_id, user_id, role[owner|editor|viewer])` - `sessions(session_id, board_id, started_at, active_user_count)` **Contenu du tableau (DynamoDB/Cassandra — haut débit d'écriture, convivial pour l'ajout) :** - **Journal des opérations :** clé de partition `board_id`, clé de tri `version` (monotone). Chaque ligne est une opération `{op_type, object_id, payload, user_id, timestamp}`. - **Instantanés :** blobs d'état complet matérialisés périodiquement `{board_id, snapshot_version, state_json/binary}` stockés dans un stockage d'objets (S3) avec une ligne de pointeur. Charger un tableau = dernier instantané + rejeu des opérations depuis cette version d'instantané. **Structure de l'objet dans un tableau :** ``` WhiteboardObject { id, type: "stroke" | "text" | "sticky", layer/zIndex, geometry: { x, y, width, height, rotation }, props: { // spécifique au type stroke: { points:[...], color, thickness }, text: { content, font, color }, sticky: { content, bgColor } }, createdBy, lastModified, version } ``` **Résolution des conflits :** Utiliser un **CRDT** (par exemple, un CRDT de liste/carte comme ceux de Yjs/Automerge) ou OT pour l'ensemble des objets, afin que les modifications concurrentes (deux utilisateurs déplaçant/modifiant des objets différents ou identiques) convergent de manière déterministe sans verrou centralisé. Chaque objet porte une horloge logique pour le dernier-écrivain-gagne sur les mises à jour de propriétés conflictuelles. **Grands actifs/actifs binaires** (images téléchargées, PNG/PDF exportés) résident dans un stockage d'objets de type S3, référencés par URL dans l'objet. ## 4. Stratégie d'évolutivité et de fiabilité **Mise à l'échelle à 10 000 sessions / 1 million d'utilisateurs :** - **Niveau d'application sans état :** Mise à l'échelle horizontale automatique derrière l'équilibreur de charge ; facile à ajouter des nœuds. - **Niveau temps réel :** Partitionné par `sessionId` via le hachage cohérent. Avec un maximum de 100 utilisateurs par tableau, 10 000 sessions = jusqu'à ~1 million de connexions WS simultanées. Un seul nœud optimisé gère ~10–50 000 connexions ; la diffusion est dimensionnée de sorte que les membres de chaque tableau se concentrent sur un seul nœud. Mise à l'échelle automatique en fonction du nombre de connexions et de l'utilisation du CPU. - **Redis :** Clusterisé, utilisé pour la diffusion Pub/Sub et la présence ; partitionné par session. - **Bases de données :** Postgres avec des répliques de lecture pour les métadonnées ; DynamoDB/Cassandra s'adaptent horizontalement pour le journal des opérations à haut volume. Le stockage d'objets s'adapte efficacement à l'infini. - **Création d'instantanés :** Des travailleurs asynchrones compactent le journal des opérations en instantanés selon une cadence (par exemple, toutes les N opérations ou T secondes) pour limiter le coût de rejeu et le stockage. **Haute disponibilité (99,9 %) :** - Déploiement multi-AZ pour chaque niveau ; multi-région pour la reprise après sinistre. - Les serveurs temps réel fonctionnent avec une veille/réplique à chaud par tableau ; en cas de défaillance d'un nœud, les clients se reconnectent automatiquement et le nouveau nœud rehydrate l'état à partir du dernier instantané + journal des opérations (les dernières secondes d'opérations en mémoire peuvent être renvoyées par les clients depuis leur tampon local). - Vérifications de l'état de santé + basculement automatisé au niveau de l'équilibreur de charge. - Backpressure et limitation de débit pour se protéger contre les tempêtes d'opérations. - Le journal des opérations durable offre un point de récupération — aucun travail validé n'est perdu même en cas de crash du serveur. ## 5. Compromis **Compromis choisi : Latence/disponibilité par rapport à la cohérence forte (AP par rapport à CP), en utilisant des CRDTs.** Je privilégie une réactivité inférieure à 200 ms et la tolérance hors ligne en laissant les clients appliquer les modifications de manière optimiste et en résolvant les conflits avec des CRDTs/dernier-écrivain-gagne, en acceptant la **cohérence éventuelle**. L'avantage : l'interface utilisateur est instantanée, les utilisateurs peuvent modifier pendant de brèves partitions réseau, et le système reste disponible pendant les basculements. Le coût : dans de rares cas d'éditions concurrentes, le résultat convergent peut ne pas correspondre aux attentes intuitives d'un utilisateur unique (par exemple, éditions simultanées du même texte), et les métadonnées CRDT ajoutent une surcharge de mémoire/stockage. Pour un tableau blanc, c'est le bon choix — la collaboration créative valorise la fluidité et la disponibilité bien plus que la cohérence sérialisée stricte qu'imposerait une approche transactionnelle/de verrouillage (CP), qui ajouterait une latence d'aller-retour et réduirait la disponibilité pendant les partitions. **Compromis secondaire :** maintenir l'état actif faisant autorité en mémoire sur un seul nœud temps réel par tableau (diffusions rapides, fusion simple) par rapport à un niveau entièrement sans état (plus résilient mais latence plus élevée). Atténué avec des instantanés + journal des opérations afin que tout nœud puisse reconstruire l'état en cas de basculement.

1. Architecture de haut niveau Une bonne conception est un hybride d'API sans état, de workers de collaboration en temps réel avec état, de stockage durable et d'un flux d'événements. Composants principaux : - Clients Web/mobiles - CDN pour les actifs statiques - Passerelle API / Équilibreur de charge - Service d'authentification - Service de métadonnées de tableau blanc - Service de collaboration en temps réel - Routeur de session / service de présence - Bus de messages / flux d'événements - Pipeline de persistance - Base de données principale pour les métadonnées - Stockage d'objets/documents pour les instantanés de tableau blanc et l'état des éléments - Cache (Redis) - Surveillance, traçage, limitation de débit Diagramme textuel : Client -> CDN pour les actifs de l'application -> Passerelle API / LB -> Service d'authentification -> Service API de tableau blanc -> Routeur de session -> Nœuds de collaboration en temps réel (WebSocket) -> État de session Redis / en mémoire -> Topic Pub/Sub ou Kafka par shard -> Workers de persistance -> Stockage d'instantanés -> DB de métadonnées Flux : - L'utilisateur ouvre l'application et s'authentifie. - Le client récupère les métadonnées du tableau blanc et le dernier état persisté via les API REST/HTTP. - Le client passe ensuite à WebSocket pour la session du tableau. - Le routeur de session envoie le client au nœud de collaboration responsable de ce tableau. - Les utilisateurs envoient des opérations telles que segment de trait de dessin, création de zone de texte, déplacement d'objet, modification de note adhésive. - Le nœud de collaboration valide, séquence et diffuse les opérations à tous les participants de la session. - Les opérations sont ajoutées à un journal d'événements et périodiquement compactées en instantanés. - Lors de la reconnexion ou de la réouverture, le client charge le dernier instantané plus les opérations récentes. Partitionnement pratique : - Utiliser le hachage cohérent ou un service de mappage tableau-nœud afin qu'une session de tableau soit détenue par un seul nœud de collaboration à la fois. - Cela simplifie l'ordonnancement et la gestion des conflits. - Avec 10 000 sessions simultanées et jusqu'à 100 utilisateurs/session, le système est vaste mais gérable avec une mise à l'échelle horizontale des nœuds de collaboration. 2. Communication en temps réel Protocole : - WebSocket sur TLS est le choix principal. - Raison : communication bidirectionnelle à faible latence, large prise en charge des navigateurs/mobiles, plus simple que le long polling, et efficace pour les petites mises à jour fréquentes. Modèle de mise à jour : - Le client envoie des opérations, pas l'état complet du tableau. - Exemples d'opérations : - start_stroke, append_stroke_points, end_stroke - create_text, edit_text - create_sticky, move_object, resize_object, delete_object - Le nœud de collaboration horodate/séquence les opérations et les diffuse à tous les clients de ce tableau. Ordonnancement et diffusion : - Au sein d'un même tableau, maintenir un numéro de séquence monotone croissant. - Toutes les opérations de ce tableau passent par son nœud de collaboration propriétaire, qui assure un ordre total par tableau. - Diffusion locale aux clients connectés ; si des répliques ou plusieurs nœuds servent le même tableau pour le basculement, utiliser Redis Pub/Sub ou Kafka pour la réplication/l'événementiel. Cible de latence inférieure à 200 ms : - Garder les nœuds de collaboration géographiquement proches des utilisateurs grâce à des déploiements régionaux. - Utiliser le routage sticky afin que tous les utilisateurs d'un tableau accèdent au même nœud dans la région lorsque c'est possible. - Diffuser uniquement les deltas, compresser les charges utiles, regrouper les points du stylo toutes les quelques millisecondes. - Pour le dessin à main levée, autoriser le rendu optimiste local immédiatement chez l'expéditeur avant l'accusé de réception du serveur, puis réconcilier si nécessaire. Gestion des conflits : - Pour les modifications basées sur des objets comme le déplacement d'une zone de texte ou la modification d'une note adhésive, utiliser le versionnement par objet. - Pour un état hautement concurrent, utiliser la transformation opérationnelle ou la fusion inspirée des CRDT si une édition multi-utilisateurs riche est nécessaire. - Pour un système de tableau blanc de haut niveau, un modèle plus simple est acceptable : - Les traits de stylo sont ajoutés en fin de liste et se fusionnent naturellement bien. - Les transformations d'objets utilisent la dernière écriture gagnante ou l'ordonnancement serveur. - Le contenu textuel peut initialement utiliser un verrouillage d'édition d'objet complet plus simple, ou évoluer plus tard vers OT/CRDT pour l'édition de texte concurrente. 3. Modèle de données Utiliser un modèle divisé : DB relationnelle de métadonnées + contenu du tableau dans un stockage de documents/blobs + journal d'opérations. A. Métadonnées du tableau blanc Table : Whiteboard - board_id - owner_user_id - title - created_at - updated_at - last_snapshot_id - access_policy - region - status Table : WhiteboardMember - board_id - user_id - role (owner/editor/viewer) - invited_at Table : ActiveSession - session_id - board_id - user_id - connection_id - joined_at - last_heartbeat - presence_state B. Modèle de contenu du tableau Représenter le tableau comme une collection d'éléments sur une toile infinie ou bornée. Champs de base de l'élément : - element_id - board_id - type : stroke | text | sticky_note | shape - created_by - created_at - updated_at - z_index - position {x, y} - rotation - objet style - version - flag deleted Élément de trait : - element_id - points : liste de points compressée par polyline ou Bézier - color - width - opacity Élément de texte : - element_id - text_content - font_family - font_size - bounding_box Élément de note adhésive : - element_id - text_content - background_color - bounding_box C. Journal des opérations Table ou flux : BoardOperation - op_id - board_id - seq_no - user_id - op_type - target_element_id - payload - client_timestamp - server_timestamp Exemples de payload : - création d'un élément avec propriétés initiales - ajout de points de trait - déplacement d'un objet de l'ancienne position à la nouvelle - patch de texte - suppression d'un élément D. Instantanés Objet instantané stocké dans le stockage de documents/blobs : - snapshot_id - board_id - base_seq_no - created_at - état du tableau sérialisé ou partitions spatiales segmentées Pourquoi des instantanés + journal d'opérations : - Rejouer l'historique complet indéfiniment devient trop lent. - Les instantanés permettent un chargement rapide. - Les opérations récentes après l'instantané restaurent l'état le plus récent. Optimisation optionnelle pour les grands tableaux : - Segmentation spatiale : partitionner la toile en tuiles/régions afin que les clients ne chargent que le contenu visible. - Utile si les tableaux deviennent très grands. 4. Stratégie d'évolutivité et de fiabilité Évolutivité A. Mise à l'échelle horizontale des nœuds de collaboration - Le service de collaboration est le chemin critique. - Chaque nœud maintient en mémoire les sessions de tableau actives qui lui sont assignées. - Les sessions sont segmentées par board_id. - Si la taille moyenne des sessions est modeste, de nombreuses sessions peuvent être hébergées par nœud. - L'équilibreur de charge + le routeur de session garantissent que les utilisateurs rejoignent le bon nœud. B. Persistance pilotée par les événements - Ne pas écrire de manière synchrone chaque point du stylo dans la base de données principale avant la diffusion ; cela nuirait à la latence. - Au lieu de cela : - le nœud de collaboration accepte l'opération - l'ajoute à un journal durable / file d'attente répliquée - diffuse immédiatement - des workers asynchrones persistent et compactent en instantanés - Pour la durabilité, utiliser Kafka/Pulsar ou un journal d'écriture anticipée répliqué avant l'accusé de réception si des garanties plus fortes sont nécessaires. C. Trafic de dessin efficace - L'outil stylo peut générer de nombreux points par seconde. - Réduire le volume en : - simplification des points côté client - regroupement des points toutes les 10 à 30 ms - encodage binaire au lieu de JSON verbeux si nécessaire - gzip/permessage-deflate sur WebSocket D. Mise en cache - Cache Redis pour les métadonnées du tableau, la présence, la carte de routage, les instantanés chauds. - Les tableaux et les autorisations récents peuvent être mis en cache pour réduire la charge de la base de données. E. Stratégie de stockage - DB relationnelle (PostgreSQL/MySQL) pour les utilisateurs, les tableaux, les autorisations, les métadonnées de partage. - Stockage d'objets/blobs (S3/stockage d'objets ou DB de documents) pour les instantanés. - Système de flux/journal pour les opérations. - Cela évite de forcer une seule base de données à gérer tous les modèles d'accès. Fiabilité / Haute disponibilité A. Déploiement multi-AZ - Exécuter les API, les nœuds de collaboration, Redis et les bases de données dans plusieurs zones de disponibilité. - Les équilibreurs de charge vérifient l'état des instances et redirigent automatiquement. - 99,9 % de disponibilité est réalisable avec le multi-AZ et les déploiements progressifs. B. Basculement des nœuds de collaboration - Comme la propriété du tableau est avec état, la défaillance d'un nœud est importante. - Atténuation : - les opérations sont continuellement répliquées dans un journal durable - points de contrôle en mémoire périodiques ou instantanés rapides - le routeur de session détecte la perte de nœud et réattribue le tableau à un autre nœud - les clients se reconnectent automatiquement et rechargent l'instantané + les opérations finales - Une courte interruption est acceptable ; les utilisateurs récupèrent rapidement. C. Présence et battements de cœur - Les battements de cœur WebSocket détectent les déconnexions. - Le service de présence met à jour l'état des utilisateurs actifs avec des TTL dans Redis. D. Contre-pression et protection - Limitation de débit par utilisateur et par tableau. - Ignorer ou fusionner les événements de déplacement/glissement excessifs. - Séparer le trafic du plan de contrôle du plan de données. - Protéger contre une session bruyante consommant toutes les ressources du nœud. E. Choix de durabilité Deux options : - Latence plus faible : accusé de réception après acceptation de l'opération en mémoire et réplication asynchrone. - Durabilité plus élevée : accusé de réception uniquement après ajout au journal répliqué. Je choisirais l'accusé de réception après ajout au journal pour les mutations d'objets et le traitement par lots pour les segments de stylo afin d'équilibrer fiabilité et vitesse. Raisonnement de capacité - 10 000 sessions simultanées x en moyenne peut-être 10 utilisateurs actifs/session font 100 000 connexions simultanées en moyenne ; pire cas 1 000 000 si toutes les sessions ont 100 utilisateurs, mais ce n'est probablement pas l'état stable prévu. La conception devrait supporter des centaines de milliers de WebSockets horizontalement. - Les nœuds de collaboration peuvent chacun supporter des dizaines de milliers de connexions inactives/légères ou moins pour les sessions lourdes, donc mise à l'échelle avec autoscaling et partitionnement par nombre de tableaux actifs et taux d'événements. 5. Compromis Compromis majeur : cohérence vs latence. Je privilégierais la faible latence et la collaboration fluide à la cohérence globale stricte pour chaque action. Ce que cela signifie : - Les clients rendent leur propre dessin immédiatement et de manière optimiste. - Le serveur fournit un ordonnancement faisant autorité par tableau, mais certaines opérations peuvent être fusionnées à l'aide de règles simples comme l'ordre serveur ou la dernière écriture gagnante. - La persistance est quasi temps réel plutôt que de bloquer chaque mise à jour sur une transaction de base de données. Pourquoi ce compromis est bon ici : - L'expérience utilisateur du tableau blanc est très interactive ; les utilisateurs remarquent le décalage beaucoup plus que des réconciliations mineures occasionnelles. - Les traits de stylo et les déplacements d'objets tolèrent la cohérence éventuelle dans une très petite fenêtre. - Des transactions sérialisables strictes pour toutes les modifications augmenteraient la latence et réduiraient le débit. Coût de ce choix : - Lors d'éditions concurrentes du même objet, les utilisateurs peuvent voir de petits sauts ou des mises à jour écrasées. - La récupération après une défaillance de nœud peut rejouer une courte séquence d'opérations. - L'édition de texte concurrente riche peut nécessiter un mécanisme OT/CRDT plus avancé plus tard. Conception résumée - API REST pour l'authentification, les métadonnées du tableau, les instantanés. - WebSockets pour la collaboration en direct. - Un nœud de collaboration propriétaire logique par tableau pour le séquençage et la diffusion. - Redis/cache pour le routage et la présence. - Kafka/PubSub/journal d'événements pour le streaming durable des opérations. - DB relationnelle pour les métadonnées/autorisations, stockage d'objets ou stockage de documents pour les instantanés et l'état du tableau. - Déploiement multi-AZ, autoscaling, reconnexion/basculement et instantanéisation asynchrone pour la fiabilité et l'échelle. Cette architecture répond à l'exigence de quasi temps réel, prend en charge la persistance, s'adapte à de nombreuses sessions actives et maintient le système opérationnellement pratique.