Event-Carried State Transfer

L'évènement transporte un snapshot de l'état métier, pas seulement son identifiant — l'aval n'a plus besoin de rappeler l'amont en synchrone.

Problème

Dans une architecture évènementielle naïve, l'émetteur publie un évènement de notification (« OrderConfirmed#42 »). Chaque consommateur doit alors appeler l'API du producteur pour récupérer l'état complet de la commande. Le système retrouve un fort couplage synchrone : si le producteur est down, les consommateurs sont bloqués ; si 50 consommateurs réagissent, on amplifie la charge par 50.

Forces

• Le couplage synchrone consommateur ↔ producteur ré-introduit les pannes en cascade que l'évènementiel devait éviter.
• Embarquer toute la donnée dans l'évènement augmente la taille des messages et la pression sur le broker.
• Un évènement avec snapshot est auto-portant : un rejeu hors ligne reconstruit l'état historique.
• La fraicheur du snapshot est figée à l'émission — l'aval doit gérer l'invalidation s'il y a un évènement plus récent.
• Les schémas évoluent : un consommateur ancien doit pouvoir ignorer des champs nouveaux sans planter.

Solution

Inclure dans l'évènement un payload qui décrit complètement l'aggregate modifié au moment T. Les consommateurs maintiennent leur copie locale (cache, materialized view) en réagissant aux évènements successifs. La règle d'or : un évènement doit suffire à reconstruire l'état nécessaire à l'aval — pas besoin de rappeler le producteur. Pour gérer la taille, on combine avec Claim Check quand le snapshot dépasse quelques KB.

Structure

Producer (Order Service)
    │ COMMIT (DB + event in same TX, see Outbox)
    ▼
┌─────────────────────────────────────────────────┐
│ Event: OrderUpdated                             │
│   id: order-42, version: 7, timestamp: ...      │
│   state: { customer, items[], totals, status }  │ ← full snapshot
└───────────┬──────────────────────┬──────────────┘
            ▼                      ▼
   Consumer A (Billing)   Consumer B (Logistics)
   updates local cache    updates local view
   no call to Producer    no call to Producer

Implémentation EDI

Dans un hub EDI, l'ECST est utile pour répliquer l'état des partenaires (PartnerProfileUpdated avec l'intégralité du profil : AS2 URL, certificat, OFTP2 SSID, EAS code), ou pour transmettre les transactions vers un lake analytique sans coupler ce dernier au transactionnel. Un évènement InvoiceIssued embarquant le UBL complet permet à un connecteur fiscalité (PEPPOL CTC) de consommer sans appeler l'ERP. À l'inverse, pour les flux à fort volume où seul l'identifiant suffit (DispatchedRow), on reste sur Event Notification.

Anti-patterns

• Snapshot anémique — l'aval doit rappeler l'amont pour les détails ; on n'a rien gagné.
• Snapshot obèse — chaque évènement embarque l'historique complet, le broker sature.
• Pas de numéro de version — le consommateur ne peut détecter qu'un évènement plus récent l'a déjà mis à jour (out-of-order delivery).
• Pas de gestion d'évolution de schéma — un nouveau champ casse un consommateur antique.
• Snapshot avec PII non-filtrées — le lake analytique reçoit des données qu'il ne devrait pas voir (RGPD).

Patterns liés

• Event Notification — alternative minimaliste sans payload.
• Event Sourcing — réutilise le même journal d'évènements mais avec persistance définitive.
• Claim Check — déporte le snapshot quand il devient trop gros.
• Outbox — garantit l'écriture atomique DB + évènement.

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 « Microservice Communication Styles ».
• Kleppmann M. — Designing Data-Intensive Applications, O'Reilly 2017, chap. 11 « Stream Processing ».