L'émergence d'architectures microservices a nécessité le modèle Saga pour gérer les transactions distribuées à travers les frontières de service où les garanties ACID traditionnelles sont impossibles. Historiquement, les tests reposaient sur des bases de données monolithiques avec cohérence immédiate, mais les systèmes polyglottes modernes nécessitent la validation des workflows asynchrones et de la logique de compensation. Le problème central est que les tests d'intégration conventionnels supposent des réponses synchrones, échouant à capturer les conditions de concurrence, les partitions réseau et les états ambigus qui se produisent lorsque certains participants de la saga s'engagent pendant que d'autres échouent.
La solution nécessite une approche de Chaos Engineering intégrée dans le banc d'essai. Architecturer un cadre utilisant Testcontainers pour orchestrer de réelles instances de PostgreSQL, MongoDB et Redis au sein de réseaux Docker isolés. Introduire Toxiproxy comme un proxy TCP programmable entre les services pour injecter de la latence, des contraintes de bande passante et des partitions réseau à des étapes précises de la saga. Utiliser Awaitility pour des assertions asynchrones basées sur le polling plutôt que des pauses statiques, et intégrer Jaeger pour le traçage distribué afin de reconstruire les chemins d'exécution exacts. Mettre en œuvre un suivi des clés d'idempotence basées sur UUID pour vérifier les sémantiques de compensation exactly-once, et construire un GlobalConsistencyValidator qui snapshot des états à travers tous les niveaux de persistance pour vérifier la préservation des invariantes.
Contexte : Une plateforme e-commerce multinationale traitait les commandes via une saga pilotée par les événements impliquant le Service d'Inventaire (PostgreSQL), le Service de Paiement (MongoDB pour les journaux de transactions) et le Service d'Expédition (Elasticsearch). L'architecture utilisait Apache Kafka pour la chorégraphie entre les microservices basés sur Java.
Description du Problème : Lors des pics de trafic, l'intermittence du réseau a provoqué le succès du traitement des paiements tandis que la réservation d'inventaire échouait, déclenchant une compensation. Cependant, la logique de compensation contenait une condition de concurrence critique où des demandes de remboursement en double étaient émises si la demande de remboursement initiale dépassait le délai, violant les contrats d'idempotence. De plus, les délais de cohérence éventuelle à travers les magasins polyglottes ont causé des faux positifs dans les tests existants qui affirmaient une restauration immédiate de l'inventaire, conduisant à des pipelines CI/CD peu fiables et à des défauts échappant au contrôle où les clients étaient facturés pour des articles non disponibles.
Approche 1 : Tests de bout en bout basés sur l'UI avec délais fixes
Nous avons d'abord envisagé d'utiliser Selenium WebDriver pour simuler les flux de paiement des utilisateurs et d'insérer Thread.sleep(5000) pour attendre le traitement asynchrone.
Avantages : Simple à mettre en œuvre, couvre l'ensemble du parcours utilisateur et ne nécessite aucun changement dans le code du service.
Inconvénients : Extrêmement fragile ; cinq secondes étaient insuffisantes sous charge et excessives pendant les périodes d'inactivité. Les pannes réseau ne pouvaient être injectées à des étapes précises de la saga, rendant impossible la reproduction de la condition de concurrence spécifique. L'approche ne fournissait aucune visibilité sur les modèles de communication HTTP inter-services ou les transitions d'état de la base de données.
Approche 2 : Tests unitaires simulés avec des bases de données en mémoire La deuxième option impliquait de simuler tous les appels de service externes à l'aide de Mockito et d'utiliser la base de données en mémoire H2 pour les tests unitaires de chaque service. Avantages : Temps d'exécution inférieur à 10 secondes, pas de dépendances d'infrastructure et résultats déterministes en isolation. Inconvénients : Échec à détecter les problèmes de sérialisation dans le monde réel, les comportements de dépassement de délai des sockets TCP ou les mécanismes de verrouillage spécifiques à la base de données présents dans PostgreSQL mais pas dans H2. La condition de concurrence d'idempotence ne se manifestait qu'avec un comportement réel des paquets réseau et l'épuisement du pool de connexions, ce que les simulations ne peuvent pas reproduire.
Approche 3 : Chaos orchestré avec une véritable infrastructure (Choisie) Nous avons mis en œuvre un banc d'essai dédié utilisant JUnit 5 et Testcontainers. Chaque service fonctionnait dans des conteneurs Docker isolés avec Toxiproxy gérant tous les liens réseau entre eux. Nous avons utilisé RestAssured pour les points d'entrée API et WireMock pour simuler le comportement d'idempotence du processeur de paiements externe. Avantages : A permis une injection de fautes précise à des étapes spécifiques de la saga (par exemple, couper la connexion après la validation du paiement mais avant la vérification de l'inventaire). Awaitility a permis d'attendre dynamiquement la cohérence éventuelle sans délais fixes. Les traces Jaeger fournissaient une analyse judiciaire des chemins d'exécution pour vérifier les routes de compensation. Inconvénients : Complexité d'installation initiale plus élevée et exigences de ressources (minimum 8 Go de RAM pour l'exécution locale), plus un temps de démarrage initial plus long par rapport aux tests unitaires.
Résultat : Le cadre a détecté le bogue d'idempotence où les tentatives de compensation n'avaient pas un bon traitement des HTTP 409 Conflict pour les clés en double. Après avoir corrigé la logique pour vérifier les clés d'idempotence Redis avant de soumettre les demandes de remboursement, les frais en double en production sont tombés à zéro. Le temps d'exécution des tests a été réduit de 8 minutes (tests UI instables) à 45 secondes (tests d'intégration ciblés) tout en améliorant la couverture des scénarios d'échec de 300%.
Comment vérifiez-vous que les transactions de compensation maintiennent l'idempotence lorsque des pannes réseau provoquent des résultats de demande ambigus ?
Les candidats affirment généralement uniquement les soldes finaux, négligeant la vérification cruciale que les systèmes en aval ont reçu exactement une demande. La bonne mise en œuvre implique de capturer la clé d'idempotence UUID avant l'injection de chaos, puis d'utiliser la méthode verify(exactly(1), postRequestedFor()) de WireMock pour confirmer qu'une seule demande correspondante a atteint la passerelle de paiement. De plus, inspectez les journaux de la machine d'état de l'Orchestrateur de Saga pour garantir que les transitions suivent COMPENSATING -> COMPENSATED sans états intermédiaires FAILED qui pourraient déclencher des alertes inutiles. Cela nécessite un contrôle de proxy au niveau TCP pour couper les connexions après que les octets de demande sont transmis mais avant que les octets de réponse n'arrivent, créant la condition exacte de délai ambigu qui teste la gestion de l'idempotence.
Quelle stratégie empêche l'instabilité des tests lors de l'affirmation de la cohérence éventuelle à travers des magasins de données hétérogènes avec des latences de réplication différentes ?
La plupart des candidats suggèrent le polling avec un délai fixe. La solution robuste utilise Awaitility avec un retour en arrière exponentiel commençant à 100 ms, plafonné à la latence de production au 99e percentile (par exemple, 3 secondes). Il est crucial de mettre en œuvre un mécanisme de Global Clock ou de Vector Clock dans les tests pour prendre un instantané des horodatages logiques à travers PostgreSQL, MongoDB et Redis avant le début de la saga. Les assertions vérifient ensuite que les opérations de lecture retournent des données avec des horodatages supérieurs ou égaux à l'heure de début de la saga. Pour les scénarios CQRS, abonnez-vous aux événements CDC en utilisant Debezium intégré dans les tests plutôt que de poller les bases de données, réduisant les temps d'attente de secondes à millisecondes et éliminant les conditions de concurrence entre l'assertion de test et la réplication des données.
Comment détectez-vous les états d'exécution partiels où certains participants à la saga se sont engagés tandis que d'autres restent en attente, sans accéder aux outils d'observabilité de production ?
Les candidats manquent souvent la nécessité de suivre la Saga In-Process ou les Journaux d'Audit de Saga accessibles au banc d'essai. La solution nécessite d'injecter un modèle Sidecar dans les conteneurs de test qui intercepte les appels gRPC ou HTTP vers les services participants en utilisant Envoy ou des proxies personnalisés. Maintenez une Matrice d'État de Saga dans le banc d'essai qui suit le statut de chaque participant (PENDING, COMMITTED, ABORTED). Lorsque Toxiproxy injecte une partition, interrogez cette matrice pour vérifier que les participants engagés correspondent aux états attendus avant la défaillance, tandis que les participants avortés ne montrent aucun effet secondaire. Utilisez des assertions JSONPath sur les balises des spans Jaeger pour confirmer que les chemins de compensation s'exécutent uniquement pour les participants engagés, garantissant que les ressources ne sont pas libérées pour des transactions qui ne les ont jamais réellement réservées.