Événements : éviter les pertes et préparer la reprise

Une commande est expédiée. Sa liste doit afficher le nouveau statut, le moteur de recherche doit être actualisé et le client doit recevoir un courriel. Ces trois traitements peuvent réussir séparément. Pour gérer leurs échecs, il faut savoir ce qui peut être recalculé et ce qui demande un suivi de l'effet réalisé.

Distinguer la vue calculée de l'action effectuée

La liste et l'index de recherche représentent des informations déjà présentes dans la commande. Ce sont des projections. Si la source conserve les données nécessaires, on peut les reconstruire.

L'envoi du courriel produit un effet extérieur. Relire la commande ne suffit pas à savoir si le message a été reçu par le service d'envoi. Il faut conserver l'intention et suivre son traitement.

Un courriel manqué n'est donc pas forcément irrécupérable. Une boîte d'envoi durable, un identifiant stable et un statut consultable chez le fournisseur peuvent permettre de le reprendre. Sans ces informations, la situation devient plus difficile à déterminer.

Repérer les trois endroits où le traitement peut s'arrêter

1. Avant la publication. La commande est enregistrée, puis le processus s'arrête avant d'envoyer l'événement.
2. Pendant le transport. Le message attend, disparaît selon les garanties de la file ou doit être retransmis.
3. Chez le consommateur. Le message arrive, mais une erreur empêche son application.

Un indicateur « événement envoyé » ne prouve pas que toutes les destinations ont terminé leur travail. La liste, l'index et le courriel demandent chacun un suivi adapté.

Lier la décision à l'intention de diffuser

Une outbox enregistre l'intention d'envoi dans la même transaction que le changement métier. Un relais la transmet ensuite. Si le processus s'arrête après la validation, l'intention reste disponible.

Cette propriété protège le départ. Elle ne prouve pas que chaque destinataire a appliqué le message. Les confirmations, les reprises et la conservation des messages complètent le dispositif.

La capture du journal de la base ou un stockage par événements peuvent aussi alimenter la diffusion. Leurs possibilités de reprise dépendent notamment de la rétention et du suivi de chaque consommateur. Aucun nom de technologie ne dispense de vérifier ces conditions.

Gérer les doublons au moment de produire l'effet

Un relais peut tomber après l'envoi mais avant sa confirmation. Il renvoie alors le même message. Pour éviter un effet supplémentaire, le consommateur peut reconnaître un identifiant déjà traité ou utiliser une opération idempotente.

La déduplication doit être reliée à l'effet. Marquer un message comme traité avant un envoi externe risque de perdre cet envoi ; le marquer après laisse un risque de répétition si le processus tombe entre les deux.

Une clé d'idempotence acceptée par le fournisseur ou une consultation de l'état de l'opération peut résoudre cette incertitude. Sans ce mécanisme, il faut définir le compromis et les cas à examiner manuellement.

Une garantie « exactement une fois » doit toujours être lue avec son périmètre : une transaction dans un système donné ne couvre pas automatiquement un courriel ou une API extérieure.

Choisir entre rejeu et reconstruction

Pour un index de commandes, relire l'état courant peut suffire. Pour un historique quotidien, cet état seul peut avoir perdu des informations. Il faut alors une source historique adaptée.

Les contrôleurs de Kubernetes illustrent une autre approche utile : comparer régulièrement l'état souhaité à l'état observé et réduire l'écart. Les événements accélèrent la réaction, tandis que la comparaison permet de retrouver un changement manqué.

Je privilégie, lorsque le coût le permet, une réparation exercée régulièrement. Un mécanisme utilisé uniquement en incident est plus difficile à connaître et à fiabiliser.

Fixer les attentes pour chaque destination

Définissez le retard acceptable, la perte tolérée, l'ordre requis et la manière de reprendre. L'index de recherche et la confirmation d'un paiement peuvent avoir des exigences très différentes.

Une version par commande peut empêcher une ancienne mise à jour d'écraser une plus récente. L'idempotence, à elle seule, ne garantit pas cet ordre.

Surveillez l'âge du travail en attente, les erreurs persistantes et la progression des consommateurs. Une absence d'événements peut être normale ; c'est l'écart entre le travail attendu et le travail effectué qui révèle un blocage.

Prévoir les erreurs qui ne disparaissent pas avec un nouvel essai

Un message illisible ou incompatible ne doit pas boucler indéfiniment. Une file de rebut permet de l'isoler, mais elle doit être surveillée et offrir une procédure de correction ou de reprise.

Pour une projection, une reconstruction peut être préférable à un long rejeu, si elle préserve toutes les informations nécessaires. Pour une action extérieure, examinez d'abord son état réel avant de la relancer.

Le contrat de propagation devient ainsi concret : ce qui a été décidé est enregistré, chaque destination a un moyen de rattrapage et les situations indécises restent visibles. Les outils de résilience servent ces garanties, chacun à une étape précise.

Sources

• T. Treat, You Cannot Have Exactly-Once Delivery, 2015.
• Kubernetes, Design Principles.
• C. Richardson, Pattern: Transactional outbox.
• M. Fowler, Event Sourcing, 2005.