Un laboratoire visuel pour construire une infrastructure, provoquer des pannes et comprendre leur propagation grâce à un moteur de simulation déterministe.
Étude de cas
01
Les pannes d’une architecture distribuée sont difficiles à expliquer avec un schéma statique : une saturation locale peut remplir une file, ralentir une dépendance puis dégrader tout le parcours utilisateur. Surgyah transforme ces relations invisibles en une expérience interactive et progressive.
02
Modéliser assez fidèlement la capacité, les files d’attente, les dépendances et les incidents pour produire des résultats utiles, tout en gardant chaque conséquence compréhensible par une personne qui découvre la résilience.
03
J’ai isolé un moteur TypeScript pur qui compile le graphe et calcule chaque état sans dépendre de l’heure ni d’un service externe. Trois missions guidées appliquent un pic de trafic, la perte d’une API et une panne PostgreSQL ; l’interface visualise leur propagation, les métriques et la chaîne causale en direct.
04
La démo publique exécute le moteur dans le navigateur pour rester immédiate, gratuite et autonome, mais elle ne persiste pas les essais. Le même moteur peut aussi tourner dans une architecture Docker où Next.js enregistre les runs, Redis Streams alimente un worker Bun et SSE diffuse les résultats.
05
La version en ligne permet de modifier une infrastructure, lancer 18 étapes déterministes, suivre CPU, files, latence et taux de succès, puis comparer deux essais avant et après amélioration. Le dépôt documente et teste aussi le parcours distribué PostgreSQL, Redis et worker.
Points clés
Chaque tick part du même état et des mêmes événements pour produire un résultat reproductible, testable sans API externe ni IA.
Le graphe, les métriques et la chaîne causale relient l’incident technique à ses conséquences concrètes pour l’utilisateur.
La démo autonome partage son cœur de calcul avec un parcours distribué associant PostgreSQL, Redis Streams, worker Bun et SSE.
Regard critique
Limite actuelle
La démo navigateur ne conserve ni les positions du canvas ni l’historique après fermeture. Dans le mode distribué, la reprise après le crash d’un worker et les commandes de pause ou d’arrêt ne font pas encore partie du MVP.
Prochaine étape
Persister la disposition du canvas et l’historique des comparaisons, puis ajouter la récupération des runs interrompus et des checkpoints au mode distribué.