Vous devez mettre à jour la base de données et publier un événement. Comment évitez-vous qu'ils se désynchronisent ?

Utilisez le motif outbox transactionnel : écrivez l'événement dans une table outbox dans la même transaction que le changement d'état, puis laissez un relais séparé la sonder ou suivre le journal pour publier l'événement et le marquer envoyé. Ainsi il n'y a qu'une seule validation, donc vous ne pouvez jamais avoir une ligne sans événement ni un événement sans ligne. Le relais donne une livraison au moins une fois, donc les consommateurs doivent rester idempotents.

Le piège, c'est qu'une validation en base et une publication dans un broker sont deux systèmes séparés, donc n'importe quel ordre choisi a un mode de défaillance. Publiez d'abord et la transaction peut être annulée, donc les consommateurs agissent sur quelque chose qui n'a jamais eu lieu. Validez d'abord et le processus peut mourir avant la publication, donc l'événement est perdu et rien ne le rejoue. Le motif outbox supprime l'écart : la ligne d'événement est insérée dans une table outbox à l'intérieur de la même transaction que le changement métier, donc soit les deux atterrissent, soit aucun. Ensuite un relais lit les lignes non envoyées dans l'ordre et les publie en les marquant envoyées, et s'il plante en pleine publication il republie simplement, ce qui est la raison pour laquelle les consommateurs doivent être idempotents. Si je suis sur Postgres et que je veux moins de sondage, j'utilise la capture de données modifiées à partir du journal des écritures avec quelque chose comme Debezium, ce qui donne la même garantie avec moins de code maison. Les détails opérationnels à prévoir sont l'élagage de l'outbox et la surveillance du retard du relais, parce qu'une outbox qui cesse de se vider a l'air parfaitement saine côté application.