Comment gérer les situations, lorsque le modèle de lecture est devenu désynchronisé avec les journaux d'événements?

Question

Lorsque les snapshots d'agrégats ne sont plus synchronisés avec le journal des événements, je peux simplement rejouer mes événements à partir des instantanés précoces (qui sont censés être synchronisés). La même chose que je peux faire quand j'ajoute/enlève de nouveaux champs ou quand je modifie la logique des gestionnaires existants.

Dans le cas où j'ai besoin d'ajouter un nouveau modèle de lecture (c'est-à-dire une nouvelle vue de rapport) je peux faire la même chose - je rejouerai mes événements.

Mais comment dois-je gérer la situation, lorsque le modèle de lecture est devenu désynchronisé avec le journal des événements? Le stockage des événements et la publication sont dans une transaction, mais la mise à jour du modèle de lecture a eu lieu dans une autre transaction, qui peut échouer. Répéter les événements depuis le début peut aider, mais cela peut prendre l'éternité. Ai-je besoin d'un concept d'instantanés pour l'ensemble du modèle de lecture?

Comment résolvez-vous ce problème? Merci.

Answer 1

Quelle serait la raison de l'échec du gestionnaire d'événements? Quelle est la durée de "l'éternité"? Les mises à jour du modèle en lecture échouent rarement (contrairement aux gestionnaires de commandes), car la logique à l'intérieur est extrêmement simple. Les pannes sont susceptibles d'être causées par des problèmes transitoires (E/S) et seront traitées automatiquement par le bus de messages. Toutefois, si le modèle de lecture est corrompu pour une raison quelconque, il est le moyen le plus simple de le réinitialiser et de diffuser des événements. Même des millions d'événements prendraient raisonnablement peu de temps. De plus, vous pouvez toujours utiliser l'approche Map-Reduce.

Je recommanderais de ne pas introduire d'instantanés pour lire les modèles. Je pense que cela ne fait que compliquer l'architecture sans gains significatifs.