Publier des événements de façon fiable avec un outbox transactionnel

Objectif

Garantir que chaque changement d'état validé (commit) produit son événement exactement au moment où le changement est validé, sans transaction distribuée entre la base de données et le broker de messages.

Prérequis

Un service propriétaire de sa base de données et publiant des événements vers un broker ; des consommateurs tolérant les doublons (déduplication par identifiant de message). La page consacrée à ce pattern sur microservices.io (citée) décrit le problème : un service doit mettre à jour sa base de données et envoyer un message de façon atomique, et les messages d'un même agrégat doivent conserver leur ordre à travers les instances du service.

Étapes

1. Créer une table outbox : id (unique, devient l'identifiant du message), aggregate_type, aggregate_id, event_type, payload (JSON), created_at, et, pour la variante par scrutation (polling) uniquement, published_at (nullable). Les noms de colonnes par défaut de Debezium sont id, aggregatetype, aggregateid, type et payload ; d'autres noms se règlent via ses options.
2. Dans la transaction applicative qui change l'état, insérer une ligne outbox par événement. Valider (commit). Rien d'autre ne se produit sur le chemin de la requête.
3. Choisir un relais :
   • Éditeur par scrutation (polling) : un worker sélectionne les lignes non publiées dans l'ordre de id (FOR UPDATE SKIP LOCKED sous PostgreSQL pour permettre plusieurs workers), publie chacune vers le broker avec l'id de la ligne comme identifiant de message et l'id de l'agrégat comme clé de partition, puis renseigne published_at.
   • Lecture du journal (log tailing) : un connecteur de capture de changement de données (CDC) lit le journal de la base. Le routeur d'événements outbox de Debezium (cité) capture les insertions dans la table outbox, route chaque ligne vers un topic dérivé du type d'agrégat et utilise l'id de l'agrégat comme clé de message. Sa documentation indique que les mises à jour des lignes outbox ne sont pas autorisées et que les suppressions sont filtrées, si bien qu'avec cette variante la table est en insertion seule : les lignes sont supprimées après coup, jamais marquées.
4. Accepter qu'un plantage entre la publication et le marquage (ou, avec la lecture du journal, entre la publication et l'enregistrement de sa position par le connecteur) produit un doublon ; l'idempotence du producteur côté broker, lorsqu'elle est proposée, couvre les nouvelles tentatives au sein d'une même session de producteur, pas un relais redémarré. Les consommateurs dédupliquent par identifiant de message.
5. Supprimer ou archiver les lignes publiées selon un calendrier ; garder la table petite pour que la requête de scrutation reste peu coûteuse.
6. Surveiller l'âge de la plus ancienne ligne non publiée et le nombre de lignes non publiées ; alerter quand le relais se bloque.

Résultat attendu

Aucun événement sans changement validé et aucun changement sans événement. Les consommateurs voient chaque événement au moins une fois, dans l'ordre par agrégat si le relais préserve l'ordre d'insertion et si le broker préserve l'ordre par clé.

Limites et base de vérification

La scrutation ajoute une latence d'un intervalle de scrutation ; la lecture du journal nécessite une infrastructure de CDC et des permissions sur la base de données. L'ordre entre agrégats différents n'est pas garanti. Tester en tuant le relais en plein milieu d'un lot et en faisant planter l'application entre l'écriture métier et le commit ; l'outbox ne doit montrer ni événements orphelins ni événements manquants.

L'ordre avec un relais par scrutation

Plusieurs workers de scrutation utilisant SKIP LOCKED ne préservent pas l'ordre par agrégat : un worker peut publier une ligne plus récente pour un agrégat avant qu'un autre worker ne publie une ligne plus ancienne, et une ligne dont l'id est plus petit peut devenir visible après une ligne dont l'id est plus grand, parce que les transactions se valident dans un ordre différent de celui des id. Si les consommateurs dépendent de l'ordre par agrégat, exécuter un seul worker de publication, ou répartir les workers selon un hachage de aggregate_id afin que les lignes d'un agrégat donné soient toujours traitées par le même worker, et scruter à partir de la plus ancienne ligne non publiée plutôt qu'à partir du dernier id vu. Le relais par lecture du journal évite les deux problèmes car il lit les validations (commits) dans leur ordre de validation.