SSE plutôt que WebSocket
Le navigateur reçoit un flux unidirectionnel de métriques. SSE couvre ce besoin avec reconnexion native et moins de protocole applicatif.
COMMENT ÇA MARCHE
Un moteur,
deux modes.
Sur la démo publique, le moteur s’exécute directement dans votre navigateur : aucun test n’est envoyé à Redis, PostgreSQL ou à un worker distant. Le mode distribué complet reste disponible dans le dépôt et se lance avec Docker pour explorer la file de travaux, la persistance et le temps réel.
MODE DISTRIBUÉ · DISPONIBLE VIA DOCKER
Le parcours d’un test dans l’architecture complète.
Ce schéma décrit le backend facultatif exécutable depuis le dépôt. Le bouton de la démo Vercel utilise, lui, le moteur dans le navigateur.1 · VOUSL’interface dans le navigateurChoix du test · réglages · résultat en direct
Lancer→Voir le résultat
2 · COORDINATIONService web · Next.jsVérifie les réglages · prépare le test · transmet les résultats
↙↘
3A · ÉTAT DURABLEPostgreSQLConserve le scénario, le statut et la progression
3B · FILE ET DIRECTRedis StreamsOrganise les tests et garde le dernier résultat
Un test est réservé↓
4 · CALCULSimulateur séparé · BunPrend un test · calcule chaque étape · publie les mesures
Calcul reproductible↓
MOTEUR DE SIMULATIONSystème → demande → capacité → attente → conséquences
Aucune IA · aucune API externe · mêmes entrées, mêmes sortiesCYCLE DU MODE BACKEND FACULTATIF
Ce que fait la version Docker après « Lancer ».
- 01Vérifier
Next.js contrôle le test, les capacités et les connexions reçues.
- 02Mémoriser
PostgreSQL garde une copie exacte et immuable de l’essai.
- 03Mettre en attente
L’essai rejoint une file Redis pour être traité dans l’ordre.
- 04Réserver
Un simulateur réserve l’essai pour éviter qu’il soit calculé deux fois.
- 05Calculer
Le moteur propage la demande, l’attente, les erreurs et le temps de réponse à chaque étape.
- 06Afficher
Redis garde le dernier état ; Next.js le transmet au navigateur en temps réel avec SSE.
DÉCISIONS DU MODE DISTRIBUÉ
Des choix proportionnés au problème.
Dans cette variante Docker, chaque séparation répond à une contrainte observable : file d’attente, persistance ou diffusion en direct.PostgreSQL comme source de vérité
Les infrastructures, versions et runs restent durables. Redis peut être vidé sans devenir l’autorité sur l’état métier.
Redis pour l’éphémère
Redis Streams transporte les jobs et les métriques récentes. Des leases empêchent deux workers de traiter simultanément le même run.
Moteur isolé du framework
Le moteur TypeScript ne dépend ni de Next.js, ni de Redis, ni de PostgreSQL. Une simulation peut être testée avec de simples objets en mémoire.
Ticks déterministes
Un même graphe, les mêmes événements et la même configuration donnent le même résultat. Aucun modèle probabiliste externe n’intervient.
Worker séparé
Les calculs longs ne bloquent pas les requêtes web. L’interface reste réactive et plusieurs runs peuvent attendre proprement dans la file.
ALGORITHME DE SIMULATION
Une panne locale devient un impact utilisateur.
Le moteur effectue d’abord une passe vers l’avant pour distribuer la demande, puis une passe inverse pour remonter le taux de succès et la latence à travers les dépendances synchrones.
Demande entrante→Routage pondéré→Capacité + file→Dépendances→Impact client
LIMITES ASSUMÉES
Un laboratoire pédagogique, pas un capacity planner cloud.
- Les chiffres sont des modèles cohérents, pas des benchmarks AWS.
- Le MVP ne simule pas le réseau paquet par paquet.
- La démo publique ne persiste pas les essais après la fermeture de la page.
- Dans le mode Docker, un run est traité par un worker, sans calcul distribué d’un même graphe.
- La reproductibilité est privilégiée face au réalisme probabiliste.
ESSAYER LE MODE PUBLIC GRATUIT