Event Notification

« Quelque chose vient de se passer, viens chercher si ça t'intéresse. » L'évènement le plus léger possible, contre du couplage synchrone résiduel.

Problème

Un système publie des modifications mais n'a pas envie de polluer le broker avec des payloads volumineux. Tous les consommateurs ne sont pas intéressés par toutes les commandes ; certains ne veulent que filtrer puis enrichir à la demande. Comment notifier sans payer le coût d'un snapshot complet ?

Forces

• Les évènements complets pèsent quelques KB voire MB ; les Notifications pèsent quelques centaines d'octets.
• Le couplage synchrone consommateur ↔ producteur est ré-introduit pour le fetch des détails.
• Le consommateur a le choix d'enrichir quand il en a besoin (lazy) au lieu de stocker un état complet.
• Pas d'auto-portance pour le rejeu : sans les détails, on ne peut pas reconstruire le passé.
• Le producteur doit exposer une API stable pour le fetch (versionnée).

Solution

L'évènement transporte un minimum : { id, type, aggregateId, version, occurredAt, source }. Le consommateur intéressé décide s'il appelle GET /orders/{aggregateId} chez le producteur pour récupérer l'état. La taille reste constante peu importe l'entité, ce qui permet de fan-out à très large échelle. Fowler insiste : Event Notification convient quand le consommateur ne consomme pas tout, et qu'il accepte une latence accrue (un round-trip de plus).

Structure

Producer
   │ publish (minimal payload, ~200 B)
   ▼
┌────────────────────────────────────────────┐
│ Event: OrderConfirmed                      │
│   id: order-42, version: 7                 │
│   occurredAt: 2026-05-16T10:42:00Z         │
│   source: order-service                    │
└──────────┬─────────────────────────────────┘
           │ Consumer X picks it
           ▼
       Consumer X
           │ GET /orders/42 (HTTP, sync)
           ▼
       Producer API (enrich on demand)

Implémentation EDI

Un hub EDI publie InvoiceIssued avec uniquement l'ID, le partenaire et le numéro UBL. Un consommateur « courtier de paiement » récupère les détails uniquement pour la sous-population qui passe par lui. À l'inverse, un consommateur fiscal CTC PEPPOL ayant besoin du payload UBL entier est mieux servi par Event-Carried State Transfer. Cas type : MdnReceived avec l'ID AS2 — un superviseur ops décide de récupérer le payload signé pour audit si la MDN signale un échec.

Anti-patterns

• Notification suivie d'un fetch sans cache — le producteur subit N appels par évènement publié.
• Pas d'idempotence sur le GET — un retry consume duplique l'enrichissement et la facture.
• Notification sans version — un consommateur ne peut détecter qu'un état plus récent a déjà été récupéré.
• Producteur sans circuit breaker — un fan-out massif fait tomber l'API d'enrichissement.
• API de fetch non versionnée — un breaking change casse tous les consommateurs.

Patterns liés

• Event-Carried State Transfer — alternative complète si l'aval a besoin de tout.
• Event Message — style de message générique.
• Content Enricher — étape qui réalise le fetch côté consommateur.
• Circuit Breaker — à appliquer sur l'API d'enrichissement.

Sources

• Fowler M. — What do you mean by "Event-Driven"?, 2017. martinfowler.com/articles/201701-event-driven.html
• Newman S. — Building Microservices, 2^e éd., O'Reilly 2021, chap. 4.
• Stopford B. — Designing Event-Driven Systems, O'Reilly 2018, chap. 6 « Event Notification ».