Performance et mise à l’échelle

Skrum est le plan de contrôle de projet tout-en-un avec IA — chat d'équipe, tâches et sprints, réunions vidéo natives et activité de code entrante dans un seul espace de travail, où chaque action de l'IA attend un accord humain.

Skrum est conçu pour rester réactif quand un espace de travail grandit et quand l'infrastructure passe une mauvaise journée. Cette page documente les chiffres concrets, le modèle de cache et les modes de panne.

Seuils de charge

Les scénarios k6 optionnels sous load/ maintiennent Skrum sur ces objectifs face à la pile composée avec des fournisseurs factices déterministes :

• Diffusion temps réel — 500 clients socket concurrents dans un même canal, latence p95 message-vers-diffusion ≤ 250 ms, taux d'erreur < 0.1%.
• POST message — p95 ≤ 200 ms à 50 rps, taux d'erreur < 0.5%.
• Lecture du tableau (GET /api/tasks?projectId=…) — p95 ≤ 150 ms à 100 rps, taux d'erreur < 0.5%.
• Recherche (GET /api/search) — p95 ≤ 300 ms à 50 rps, taux d'erreur < 1%.
• Résumé de l'accueil (GET /api/home/summary) — p95 ≤ 200 ms à 100 rps, taux d'erreur < 0.5%.

Cache de lecture (read-through)

Un petit cache de lecture adossé à Redis couvre trois chemins critiques : la liste des canaux par espace de travail, les projections du tableau projet et le résumé du tableau de bord/accueil. Chaque clé est préfixée par l'accountId de l'espace de travail — un espace de travail ne peut lire que ses propres données mises en cache. L'invalidation est pilotée par les événements de la colonne vertébrale temps réel (message.posted, channel.*, task.*), avec un TTL court en filet de sécurité. Le cache ne stocke que des projections déjà autorisées et non sensibles.

Résilience au chaos

Quand une dépendance tombe, Skrum échoue en mode fermé plutôt que d'écrire partiellement ou de laisser fuir des données.

• Redis en panne. Le temps réel et le cache se dégradent ; REST continue de servir la source de vérité depuis Mongo et Postgres. Les limiteurs de débit échouent en mode sûr (refus, ne laissent jamais passer).
• Mongo ou Postgres injoignables. Les routes renvoient une erreur localisée de classe 503 — pas de crash non géré, pas d'écriture partielle.
• MinIO ou LiveKit en panne. Les téléversements de fichiers et les réunions échouent en mode fermé avec une erreur localisée ; le reste de l'app continue de fonctionner. Voir Sauvegarde et restauration.

Quand la dépendance revient, le service reprend automatiquement — aucun redémarrage manuel n'est nécessaire.

FAQ

• Est-ce que j'exécute la suite k6 en CI ? Oui, derrière une tâche optionnelle. Les scénarios de charge ne bloquent jamais une pull request normale.
• Puis-je augmenter le TTL du cache ? Le TTL est volontairement court. L'invalidation pilotée par événements est le chemin principal de correction ; le TTL n'est qu'un filet de sécurité en cas de panne Redis.
• Le cache peut-il fuir entre espaces de travail ? Non — chaque clé est préfixée par l'accountId et un test dédié prouve l'isolation entre locataires.

Voir aussi: Documentation Skrum