Dans une plateforme de commandes, la confirmation d’un achat peut déclencher le suivi logistique, le calcul des volumes et une notification. Chaque application destinataire doit reconnaître l’événement publié, sa version et les traitements déjà exécutés pour éviter de reproduire une opération à la réception d’un doublon.
Le contrat d’échange fixe ces propriétés. Il permet de faire évoluer les applications sans imposer que toutes exécutent le même traitement au même instant. L’exemple suivant suit une commande depuis son enregistrement jusqu’à une vue de consultation ; il illustre un mécanisme de conception, sans décrire une entreprise particulière.
La portée de la confirmation par l’API
L’API reçoit la demande de validation et applique les règles de la commande. Une réponse positive peut confirmer l’enregistrement de la commande sans signifier que toutes les applications destinataires ont déjà été mises à jour. Cette distinction appartient au contrat exposé à l’appelant.
L’événement signale qu’une commande a été confirmée. Il contient un identifiant d’événement, la référence de la commande, sa version et les champs nécessaires aux traitements destinataires. Le suivi logistique et l’analyse des volumes peuvent consommer ce même événement et mettre à jour leurs propres données.
Relier l’écriture à la publication
Enregistrer la commande puis envoyer un message dans deux opérations indépendantes laisse une fenêtre d’incohérence. La commande peut être enregistrée sans que son événement soit publié. Le mécanisme d’outbox transactionnelle conserve la commande et l’événement à publier dans une même transaction de base de données. Un relais transmet ensuite les événements enregistrés. La description du modèle outbox par AWS présente ce découplage et le besoin de traiter les livraisons répétées.
Le relais peut publier un message puis s’interrompre avant d’enregistrer sa progression. L’événement sera envoyé de nouveau. Le service destinataire, appelé consumer, conserve les identifiants déjà traités et enregistre sa mise à jour avec cette trace. L’effet sur les données dépend donc du traitement réalisé à l’arrivée, en plus des garanties du transport.
Préserver le sens des versions
La projection de lecture conserve les champs de commande utiles à la consultation, son statut et la date de mise à jour. Elle peut être reconstruite depuis l’historique des événements ou réinitialisée depuis la base de référence. La séparation des modèles d’écriture et de lecture, appelée CQRS, permet d’optimiser les requêtes de consultation indépendamment des transactions de commande. Le pipeline de publication assure leur synchronisation.
Lorsqu’une correction arrive avant un événement plus ancien, le numéro de version de la commande permet de rejeter l’état périmé ou de détecter une version manquante. Kafka conserve l’ordre des messages dans une partition. La clé de partitionnement doit donc regrouper les événements dont l’ordre doit être conservé, selon les mécanismes décrits dans la documentation d’Apache Kafka.
L’évolution du schéma demande la même attention. Ajouter un champ facultatif et modifier le sens d’un champ existant n’ont pas le même effet. Le contrat décrit les valeurs absentes, les anciennes versions acceptées et la règle de conversion. Un message techniquement lisible peut être sémantiquement incompatible.
Rendre l’état de l’échange observable
La supervision mesure le nombre d’événements enregistrés dans l’outbox, publiés dans le broker et appliqués aux projections. Elle suit aussi le retard de publication, les erreurs de transformation et les messages placés en file d’erreur. Ces mesures permettent de distinguer un retard de transport d’une mise à jour rejetée par l’application destinataire.
Dans l’exemple, la commande conserve son état de référence, tandis que la vue de lecture annonce la version qu’elle a intégrée. Les applications peuvent évoluer séparément tout en partageant une règle claire sur la signification d’une donnée et sur le moment où elle devient visible.