Réponse à la question
Le modèle CQRS (Command Query Responsibility Segregation) est né des pratiques de conception axées sur le domaine pour résoudre les goulets d'étranglement en matière de scalabilité dans les scénarios à fort volume de lectures en séparant les modèles optimisés pour l'écriture (PostgreSQL, Oracle) des projections optimisées pour la lecture (Elasticsearch, MongoDB). Cette bifurcation architecturale crée un retard temporel inhérent entre la persistance des commandes et la disponibilité des requêtes, car les processeurs d'événements asynchrones doivent dénormaliser les données à travers des frontières réseau avant que les modèles de lecture ne reflètent les changements d'état.
Le problème fondamental dans l'automatisation de ces systèmes découle de la condition de concurrence entre les threads d'exécution des tests et les travailleurs de projection en arrière-plan, où les assertions contre les modèles de lecture immédiatement après la soumission de commandes échouent de manière imprévisible en raison du délai de traitement. Les solutions traditionnelles reposent sur des délais arbitraires ou un polling naïf, ce qui ralentit les pipelines à des vitesses inacceptables ou produit de faux négatifs sous le stress de l'infrastructure.
La solution robuste met en œuvre un suivi de position d'événement utilisant des offsets de flux ou des jetons de capture de données de changement (Debezium, groupes de consommateurs Kafka) pour établir une barrière de synchronisation déterministe. Les frameworks de test capturent la position du dernier événement de domaine émis et interrogent les métadonnées du modèle de lecture jusqu'à ce qu'elles confirment la consommation de cette position spécifique, utilisant des retours exponentiels avec des délais de sécurité pour éviter un blocage indéfini tout en maintenant une précision d'alignement sous-seconde.
Situation de la vie réelle
Lors de l'architecture de l'automatisation des tests pour une plateforme de trading haute fréquence, notre équipe a rencontré une instabilité critique dans les tests de valorisation de portefeuille qui utilisaient PostgreSQL pour la persistance des exécutions de transactions et Elasticsearch pour les requêtes de solde en temps réel. Les tests exécutant des commandes d'achat/vente et interrogeant immédiatement les points de terminaison du portefeuille recevaient des soldes prétransaction stables parce que les projections Kafka Connect nécessitaient 300 à 800 ms pour indexer les mises à jour, causant 35 % des builds CI à échouer de manière erronée.
Notre première solution envisagée a inséré des instructions fixes Thread.sleep(2000) après chaque opération d'écriture, garantissant l'achèvement de l'indexation Elasticsearch avant les assertions. Cette approche a stabilisé temporairement les résultats mais a augmenté le temps d'exécution de la suite de 400 %, a créé des dépendances de temps fragiles sur les performances du matériel, et est restée vulnérable aux pauses de collecte de déchets ou à la congestion du réseau qui dépassaient occasionnellement le délai fixe.
La deuxième approche évaluée a mis en œuvre un polling générique avec un retour exponentiel sur le point de terminaison de la requête, réessayant les assertions jusqu'à ce que les valeurs attendues apparaissent ou qu'un délai soit écoulé. Bien que supérieure aux pauses fixes, cette méthode souffrait d'ambiguïté entre les états "pas encore mis à jour" et "valeur incorrecte", et ne pouvait pas gérer les scénarios de test concurrents où plusieurs exécutions modifiaient simultanément des agrégats identiques, entraînant une pollution croisée des tests et des faux positifs.
Nous avons finalement sélectionné une troisième approche impliquant l'instrumentation de la couche de projection pour exposer les derniers offsets Kafka traités dans les métadonnées du document Elasticsearch. Notre banc d'essai a capturé l'offset de l'événement publié en commande et a utilisé un utilitaire d'attente spécialisé qui interrogeait le modèle de lecture jusqu'à ce que ses métadonnées indiquent que cet offset avait été consommé, garantissant la cohérence sans devinette temporelle. Cela a réduit le temps moyen d'exécution des tests de 52 secondes à 14 secondes et a éliminé complètement les faux négatifs en transformant l'incertitude asynchrone en points de synchronisation déterministe.
Ce que les candidats oublient souvent
Comment empêchez-vous l'interférence des données de test lorsque plusieurs exécuteurs CI parallèles mettent à jour simultanément des agrégats qui partagent des projections de modèles de lecture sans introduire de mécanismes de verrouillage qui violent la nature asynchrone de CQRS ?
Réponse : Implémentez une isolation logique des locataires à l'aide d'identifiants d'agrégat suffixés par UUID et d'ID de corrélation d'exécution de test intégrés dans les métadonnées des événements. Configurez les indices du modèle de lecture pour inclure l'identifiant de l'exécution de test comme clé de routage ou paramètre de filtre, garantissant que les requêtes de projection ne renvoient que des documents pertinents au contexte d'exécution de test spécifique. Cela permet l'exécution parallèle des tests sans verrous physiques de base de données tout en maintenant une stricte ségrégation des données entre les instances de pipeline concurrentes.
Quelle est la différence architecturale fondamentale entre la validation du comportement du modèle d’écriture et celle du modèle de lecture dans CQRS, et pourquoi cette distinction nécessite-t-elle différentes stratégies d'assertion ?
Réponse : La validation du modèle d'écriture se concentre sur l'atomicité transactionnelle, l'application des invariants métier, et l'exactitude de l'émission des événements de domaine, utilisant généralement des capacités de rollback des transactions de base de données pour maintenir l'isolation des tests. La validation du modèle de lecture concerne la précision de la dénormalisation, les délais de réponse des requêtes SLA, et la conformité à la fenêtre de cohérence éventuelle, nécessitant des assertions qui tiennent compte des délais de traitement asynchrone et vérifient que les projections gèrent les événements en double ou la livraison hors séquence de manière idempotente.
Comment architectureriez-vous des tests automatisés pour vérifier que les modèles de lecture gèrent correctement la livraison d'événements hors séquence ou le traitement des événements en double sans compromettre l'intégrité des données, en particulier lorsque les projections mettent en œuvre un contrôle de concurrence optimiste ?
Réponse : Construisez un banc d'essai d'injection de fautes qui publie délibérément des événements hors séquence en utilisant la réaffectation de partition Kafka ou la manipulation d'horodatage, puis affirme que le modèle de lecture soit en train de mettre en file d'attente et de réordonner les événements en utilisant des horloges vectorielles ou d'appliquer des mises à jour idempotentes basées sur des numéros de version d'agrégat. Vérifiez que la projection maintienne une cohérence monotone en vérifiant que les numéros de séquence ne diminuent jamais et que les événements redélivrés (simulés par une réinitialisation manuelle d'offset) ne créent pas de dossiers fantômes ou n'incrémentent pas plusieurs fois des compteurs dans le magasin de requêtes.