Traitement d'un grand nombre d'événements dans le cadre du sourcing d'événements

Question

Le CQRS avec l'approvisionnement en événements semble parfaitement adapté à l'architecture de l'un de nos systèmes, il n'y a qu'une seule petite chose qui nous inquiète actuellement : La gestion d'un grand nombre d'événements et la gestion d'énormes magasins d'événements en conséquence.

Notre système actuel reçoit environ un million d'événements par jour (qui n'ont actuellement rien à voir avec l'approvisionnement en événements), si nous devions les stocker tous sur une plus longue période de temps, nos magasins d'événements pourraient devenir assez grands, mais si nous vidons/purgeons vers un instantané roulant fréquemment, nous pourrions perdre l'un des grands avantages de l'approvisionnement en événements : les informations sur l'histoire du système et la relecture.

Quelles sont les façons courantes de traiter ce problème dans une architecture CQRS ? S'agit-il d'un problème à proprement parler ? Devons-nous simplement ajouter du matériel au magasin d'événements ou pouvons-nous faire quelque chose au niveau de la conception de l'architecture ?

Answer 1

Je pense que l'approche la plus courante consiste à utiliser des instantanés et des modèles de lecture persistants. En d'autres termes, vous ne rejouez pas vos événements très souvent, sauf lorsque vous devez créer un nouveau modèle de lecture ou modifier le fonctionnement d'un modèle existant. En stockant des instantanés de vos objets de domaine, vous évitez de devoir rejouer de longs flux d'événements.

On pourrait dire que le stockage d'instantanés et de modèles de lecture persistants n'est pas très différent de la simple utilisation de CQRS sans approvisionnement par événement. Mais les anciens événements sont là au cas où vous feriez une erreur dans votre modèle de lecture, ou si vous deviez dériver de nouvelles informations, ou si vous aviez d'autres exigences strictes en matière d'audit.

Dans notre application, où nous avons beaucoup d'événements qui ont une faible valeur commerciale, nous prévoyons d'épurer fortement les événements pendant l'exécution afin que nos journaux d'événements restent plus petits. Mais j'imagine que pour certains objets, nous nous rabattrons encore sur les instantanés et les modèles persistants.

Answer 2

Regardez votre "active streamset". Y a-t-il des flux qui ont un cycle de vie tel qu'ils ont tendance à naître, à muter sur une période relativement courte, puis à mourir lorsqu'ils atteignent leur état final ? Si c'est le cas, ces flux pourraient être déplacés vers un stockage moins coûteux (sauvegarde). La seule raison pour laquelle vous en avez besoin est la relecture, donc vous pouvez soit les rendre encore accessibles (bien qu'avec un taux de réponse plus lent), soit conserver une copie compressée pour la relecture. Dans tous les cas, demandez-vous s'il existe des flux que vous pouvez déplacer hors du magasin d'événements ou au moins hors du streamset actif.

Une autre option consiste à partitionner vos flux sur plusieurs magasins d'événements physiques. Il existe peut-être une frontière géographique qui peut être utilisée, ou peut-être quelque chose qui les cloisonne naturellement (le domaine dans lequel vous vous trouvez fournit généralement des indications). C'est le genre de chose pour laquelle vous devez réfléchir aux avantages et aux inconvénients.

Cette technique n'est pas limitée au sourcing d'événements. Elle peut également être appliquée aux modèles basés sur l'état (ce ne sont que des données après tout).