Noyau Event-Driven

Qu'est-ce qu'un noyau Event-Driven

Le noyau Event-Driven (EDC) est la « colonne vertébrale » de l'architecture, dans laquelle les faits commerciaux sont enregistrés et diffusés comme des événements immuables, tandis que le reste de la fonctionnalité (lecture, intégration, analyse, cache, notations) est construit au-dessus du flux de ces événements. Le noyau définit le contrat d'événement, les règles de livraison et les invariants d'ordre/idempotence, ce qui garantit une faible connectivité et évolutivité.

L'idée clé est d'abord d'écrire un fait (noyau), puis de l'enrichir indépendamment et de le projeter dans les bons modèles. Cela réduit la connectivité et augmente la résistance aux défaillances partielles.

Objectifs et propriétés d'EDC

La vérité des faits : chaque événement est un enregistrement immuable de « ce qui s'est passé ».
Faible connectivité : les producteurs ne connaissent pas les consommateurs ; extension du système - ajout d'abonnés.
Mise à l'échelle : croissance horizontale par lot/topics, consommateurs indépendants.
Observabilité et audit : Identifiants de bout en bout, reproductibilité, rétrospectivité et refonte.
Évolution contrôlée : versions des schémas, compatibilité, déprécation.

Composants architecturaux

1. Bus/courtier d'événements : Kafka/NATS/Pulsar/SNS + SQS - canaux, lots, retences.
2. Registre des schémas : JSON Schema/Avro/Protobuf pour la compatibilité et l'évolution.
3. Outbox/circuit CDC : fixation atomique de fait + publication sans « double enregistrement ».
4. Projections/lectures (CQRS) : représentations matérialisées pour les requêtes rapides.
5. Saga/orchestration : coordination des processus de longue durée à travers des événements/équipes.
6. Enrichissement : topics individuels '.enriched '/' .derived' sans affecter la voie critique.
7. Observability : trace, logigation, métriques par événement et par lagune.

Modèle d'événement

Types d'événements

Domain Events : Faits d'affaires ('paiement. authorized`, `kyc. approved`).
Integration Events : orientés vers des systèmes externes (stables, en évolution lente).
Changement de capture de données (CDC) : modifications techniques de l'enregistrement (utiliser pour les migrations/intégrations).
Audit/Télémétrie : actions des acteurs, sécurité, SLA.

Attributs obligatoires (noyau)

json
{
"event_id": "uuid",
"event_type": "payment. authorized. v1",
"occurred_at": "2025-10-31T11:34:52Z",
"producer": "payments-service",
"subject": { "type": "payment", "id": "pay_123" },
"payload": { "amount": 1000, "currency": "EUR", "method": "card" },
"schema_version": 1,
"trace_id": "abc123",
"partition_key": "pay_123"
}

Recommandations : 'event _ id' est globalement unique, 'partition _ key' définit l'ordre de l'entité, 'trace _ id' fournit la corrélation.

Sémantique de livraison et idempotence

At-least-once (par défaut chez de nombreux courtiers) : les consommateurs sont obligés d'être idempotent.
At-most-once : acceptable uniquement pour les télémétries secondaires.
Exactly-once : atteint au niveau du flux et du stockage par le biais de transactions/clés/araignées idempotent (plus cher, besoin d'une bonne raison).

Modèle d'idempotence du consommateur

Table de déduplication par 'event _ id '/' (event_id, consumer_id)' avec TTL ≥ retence de la pointe.
Upsert au lieu d'insert ; le versionage des projections par 'sequence '/' occurred _ at'.
Opérations dans le cadre d'une transaction : marque « vu » + changement d'état.

Ordre et répartition

Ordre garanti dans le lot.
Sélectionnez 'partition _ key' pour que tous les événements d'une même entité d'agrégat entrent dans le même lot ('user _ id', 'payment _ id').
Évitez les « clés chaudes » : hachage avec sel/sous-clés si vous voulez répartir la charge.

Schémas et évolution

Additive-first : nouveaux champs optionnels, interdiction de changer de type/sémantique sans version majeure.
Compatibilité : BACKWARD/FORWARD dans le registre des schémas ; CI bloque les modifications incompatibles.
Nom : 'domain. action. v{major}` (`payment. authorized. v1`).
Migrations : publier les paires 'v1' et 'v2' en parallèle, fournir un double rayonnement (dual-write via outbox), filmer 'v1' après la transition.

Outbox и CDC

Outbox (recommandé pour les services transactionnels)

1. Dans une seule transaction OBD : nous enregistrons l'enregistrement de domaine et l'événement dans la boîte de sortie.
2. Pablisher de fond lit outbox, publie dans le courtier, marque « envoyé ».
3. Garantie : pas de « perte » de fait dans les chutes, pas de dissynchronisation.

CDC (Change Data Capture)

Convient aux systèmes/migrations existants ; la source est le logue de réplication OBD.
Nécessite un filtrage/transcodage en événements de domaine (ne diffusez pas les tables « brutes »).

CQRS et projections

Les commandes changent d'état (souvent synchrone), les événements forment des projections (asynchrones).
Les projections sont conçues pour les requêtes (recherche, listes, rapports) et mises à jour par les abonnés.
La dissynchronisation temporelle est la norme : montrez un UX stable (« les données seront mises à jour en quelques secondes »).

Sagas : coordination des processus

Orchestration : un coordinateur envoie des équipes et attend les événements.
Chorégraphie : les participants réagissent aux événements des uns et des autres (plus simple mais nécessitant une discipline dans les contrats).
Règles : compensations claires et délais, étapes répétables, manipulateurs idempotent.

Observabilité

Trace/Span : passez 'trace _ id '/' span _ id' à travers les titres lorsque des événements sont générés.
Métriques : consommation, taux de publication/consommation, taux de déad-letter, proportion de déduplication.
DLQ/parking lot : messages échoués - dans un top séparé avec alert ; assurer le réemploi.

Sécurité et conformité

Classification des données : le noyau ne contient que le minimum nécessaire de PII/findans (modèle de pyramide inverse), les détails sont dans les enrichissements.
Signature/hachage des attributs critiques, contrôle de l'intégrité.
Cryptage in-flight et at-rest, partitionnement des droits par thème/consumers (IAM/ACL).
Politiques de rétractation et de droit à l'oubli : clairement définies pour chaque axe.

Performance et durabilité

Backpressure : les consommateurs ont une limitation de la concurrence, le courtier a des quotas/limites.
Batch-traitement et compression : regroupez les enregistrements pour réduire les frais généraux.
Retrai avec gitter et DLQ au lieu de tentatives sans fin.
Rebalance : Stockez les offsets de manière transactionnelle/externe, accélérez le démarrage à froid avec des snapshots.

Modèles d'événements types

Noyau de paiement

`payment. initiated. v1` → `payment. authorized. v1` → `payment. captured. v1` → `payment. settled. v1`

Refus : 'paiement. declined. v1`, `payment. refunded. v1`

Lot : 'payment _ id'

SLA : lag noyau ≤ 2c p95 ; l'idempotence des consommateurs est obligatoire.

CUS/vérification

`kyc. started. v1` → `kyc. document. received. v1` → `kyc. approved. v1`/`kyc. rejected. v1`

PII - minimum ; les détails du document sont dans 'kyc. enriched. v1 'avec accès restreint.

Audit/sécurité

`audit. recorded. v1 'avec les attributs' actor ',' subject ',' action ',' occurred _ at', 'trace _ id'.
Rétention/archivage continu ; intégrité accrue (stockage WORM).

Anti-modèles

Fat Event : surchargé payload's sans besoin, fuite PII.
Hidden RPC à travers les événements : attendre des réponses synchrones « ici et maintenant ».
CDC crus vers l'extérieur : lien étroit avec le circuit OBD.
Il n'y a pas d'idempotence chez les consommateurs : les prises conduisent à des effets secondaires doubles.
Un point commun est le conflit d'intérêts, l'ordre problématique, l'évolution complexe.

Mise en œuvre étape par étape d'EDC

1. Cartographie du domaine : Sélectionnez les agrégats clés et les cycles de vie.
2. Annuaire des événements : titres, sens, invariants, champs obligatoires.
3. Schémas et registre : sélectionnez le format, activez les règles de compatibilité.
4. Outbox/CDC : pour chaque producteur, identifiez le mécanisme de publication des faits.
5. Lot : sélectionnez les clés et évaluez les clés chaudes/redécoupage.
6. Idempotence : modèle de déduction + transaction des consommateurs.
7. Projections : identifiez les modèles matérialisés et les mises à jour SLA.
8. Observabilité : traçabilité, lagunes, DLQ, alertes.
9. Sécurité/PII : classification des données, cryptage, ACL.
10. Hyde par évolution : la politique des versions, deprecate, dual-write pour les migrations.

Chèque-liste de production

• Chaque événement a 'event _ id', 'trace _ id', 'occurred _ at',' partition _ key '.
• Les schémas dans le registre, les contrôles d'interopérabilité sont inclus.
• L'idempotence des consommateurs a été mise en œuvre et testée.
• Mis en place par DLQ/parking lot et alerte sur les erreurs de publication/consommation.
• Les projections sont recréées à partir de la loge (replay) avec un temps acceptable.
• Accès limité aux IPI ; payload's minimum dans le noyau.
• Les SLA par laga/livraison sont mesurés et visibles sur les dashboards.
• Il existe un plan de migration des versions des événements et des fenêtres du deprecate.

FAQ

En quoi EDC diffère-t-elle du « simple pneu » ?
Le noyau n'est pas seulement un courtier, mais aussi un contrat d'événements, des règles d'ordre/idempotence, des processus d'évolution et d'observation.

Ne peut-on construire que sur CDC ?
Les CDC sont adaptés aux intégrations/migrations, mais les événements de domaine expriment plus clairement le sens et vivent des changements OBD plus stables.

Qu'en est-il de la cohérence ?
Nous acceptons la consistance eventuelle et nous concevons UX/processus en dessous (indicateurs de mise à jour, rétroactions, compensation).

Quand veux-tu exactly-once ?
Rarement : quand le doublement est strictement inacceptable et impossible à compenser. Plus souvent, at-least-once + idempotence est suffisant.

Résultat

Le noyau Event-Driven transforme le flux de faits commerciaux en une base solide du système. Des contrats d'événements clairs, la discipline de la livraison et l'observabilité donnent l'évolutivité, la résilience et la rapidité de l'évolution - sans les liens synchrones fragiles et la « tempête » des régressions en cas de changement.