Kernel Event-Driven

Cos'è un kernel Event-Driven

Il kernel Event-Driven (EDC) è una colonna vertebrale di un'architettura in cui i fatti aziendali vengono registrati e diffusi come eventi invariati, mentre il resto della funzionalità (lettura, integrazione, analisi, cache, notifica) si basa sul flusso di questi eventi. Il kernel specifica il contratto eventi, le regole di consegna e gli invarianti ordine/idampotenza, garantendo una scarsa connettività e scalabilità.

L'idea chiave è di scrivere il fatto (kernel), quindi arricchirlo e proiettarlo in modo indipendente nei modelli desiderati. Ciò riduce la connettività e migliora la resistenza ai guasti parziali.

Obiettivi e proprietà EDC

La verità dei fatti è che ogni evento è una registrazione immutabile dì cosa è successo ".
Scarsa connettività: i produttori non conoscono i consumatori; estensione del sistema - aggiunta di abbonati.
Scalabilità: crescita orizzontale su partizioni/topic, consumatori indipendenti.
Osservabilità e verifica: identificatori passanti, riproducibilità, retenzioni e ripetizione.
Evoluzione guidata: versioni degli schemi, compatibilità, deprecation.

Componenti architettonici

1. Bus/broker eventi: Kafka/NATS/Pulsar/SNS + SQS - canali, partenze, retenze.
2. Registro degli schemi: JSON Schema/Avro/Protobuf per compatibilità e evoluzione.
3. Tracciato Outbox/CDC - Fissazione atomica del fatto + pubblicazione senza «doppia voce».
4. Proiezioni/letture (CQRS) - Visualizzazioni materializzate per query rapide.
5. Sags/orchestrazione: coordinare processi di lunga durata attraverso eventi/comandi.
6. Arricchimento: singoli topici' .enriched '/' .derived ', senza influire sul percorso critico.
7. Tracciabilità, logica, metriche per eventi e lame.

Modello di eventi

Tipi di eventi

Domain Events - Fatti aziendali ('payment. authorized`, `kyc. approved`).
Integration Events è incentrato sui sistemi esterni (stabili, lentamente).
Cambio Data Capture (CDC) - Modifiche tecniche alla scrittura (utilizzate per migrazioni/integrazioni).
Audit/Telemetry: azioni degli attori, sicurezza, SLA.

Attributi obbligatori (kernel)

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"
}

Raccomandazioni: 'event _ id' è univoco globalmente, 'partition _ key'imposta l'ordine dell'entità,' trace _ id 'fornisce una correlazione.

Semantica di spedizione e idimpotenza

At-least-once (predefinito per molti broker): i consumatori devono essere idipotenti.
At-just-once: accettabile solo per le telemetrie secondarie.
Exactly-once: si ottiene a livello di flusso e di storage attraverso transazioni/chiavi/leucs idipotenti (più costoso, per una buona ragione).

Modello di idampotenza del consumatore

Tabella di deduplicò event _ id '/' (event _ id, consumer _ id) 'con TTL di retenza topica.
Upsert invece di insert; versioning delle proiezioni per sequence/occurred _ at.
Operazioni all'interno della transazione - Segno «visto» + modifica dello stato.

Ordine e partizionamento

Ordine garantito all'interno della partitura.
Scegli partition _ key'in modo che tutti gli eventi di una stessa aggregazione di entità finiscano nella stessa partitura ('user _ id', 'payment _ id').
Evitare «chiavi calde»: hash con sale/sotto-chiave se si desidera distribuire il carico.

Schemi e evoluzione

Additive-first: nuovi campi opzionali, divieto di cambio tipo/semantico senza versione maggiore.
Compatibilità: BACKWARD/FORWARD nel registro degli schemi; CI blocca le modifiche incompatibili.
La denominazione è «domain». action. v{major}` (`payment. authorized. v1`).
Migrazioni: pubblicare le coppie v1 e v2 in parallelo, fornire doppia radiazione (dual-write tramite outbox), togliere «v1» dopo la transizione.

Outbox и CDC

Outbox (consigliato per i servizi transazionali)

1. In una singola transazione database, salvare il record di dominio e l'evento in outbox.
2. Il pub di sfondo legge outbox, pubblica in broker, contrassegna «inviato».
3. Garanzie: niente «perdita» di un fatto in caso di caduta, nessuna dissincronizzazione.

CDC (Change Data Capture)

Adatto ai sistemi/migrazioni esistenti sorgente - Loga della replica del database.
Richiede filtraggio/sovrapposizione negli eventi di dominio (non trasmettere tabelle crude in bianco).

CQRS e proiezioni

I comandi modificano lo stato (spesso sincronizzato), gli eventi generano le proiezioni (asincrona).
Le proiezioni sono basate su query (ricerca, elenco, report), aggiornate dagli iscritti.
La temporanea risincronizzazione è la norma: mostra un UX sostenibile («i dati verranno aggiornati in pochi secondi»).

Attività di coordinamento dei processi

Un coordinatore manda squadre e aspetta gli eventi.
Coreografia: i partecipanti rispondono agli eventi reciprocamente (più semplice, ma richiede disciplina negli appalti).
Regole: compensi chiari e timeout, passaggi ripetuti, elaboratori idropotenti.

Osservabilità

Trace/Span: scorrere «trace _ id »/« span _ id» attraverso le intestazioni quando si generano eventi.
Metriche: gruppo di consumatori, velocità di pubblicazione/consumo, dead-letter rate, percentuale di deduplicazione.
DLQ/parcheggio lot: messaggi non corretti - in un singolo top con alert; Assicuratevi che il lavoro venga rifatto.

Protezione e conformità

Classificazione dati: il kernel contiene solo i minimi PII/find necessari (modello piramide inversa) e le parti in arricchimenti.
Firma/hash attributi critici, controllo integrità.
Crittografia in-flight e at-rest, secessione dei diritti per argomento/console (IAM/ACL).
Le politiche di reticenza e il diritto all'oblio sono ben definiti per ogni topic.

Prestazioni e sostenibilità

Backpressure: i consumatori hanno limitazioni di competitività, il broker ha quote/limiti.
Elaborazione e compressione Batch: raggruppa i record per ridurre i costi generali.
Retrai con jitter e DLQ invece di tentativi infiniti.
Robustezza Rebalance - Memorizzare gli off-set transazionali/esterni, accelerare la partenza fredda con snapshot.

Modelli di evento tipici

Core di pagamenti

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

Guasti dì payment ". declined. v1`, `payment. refunded. v1`

Partizione'payment _ id '

SLA: kernel ≤ 2s p95; l'idipotenza dei consumatori è obbligatoria.

CUS/verifiche

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

PII - minimo; parti del documento in "kyc. enriched. v1 'con accesso limitato.

Controllo/protezione

`audit. recorded. v1 'con attributi «attore», «subject», «action», «occurred _ at», «trace _ id».
Ritenzione/archiviazione continua maggiore integrità (WORM).

Antipattern

Fat Event: payload sovraccarico senza necessità, fuoriuscita PII.
Hidden RPC attraverso gli eventi: in attesa delle risposte sincrono «qui e ora».
CDC crudi verso l'esterno, una stretta connettività con il sistema di database.
Non c'è idepotenza nei consumatori, le riprese portano a doppi effetti collaterali.
Una cosa comune è il conflitto di interessi, l'ordine problematico, l'evoluzione complessa.

Implementazione passo per passo di EDC

1. Mappatura dominio - Selezionare le unità chiave e i cicli di vita.
2. Elenco eventi: nomi, significati, invarianti, campi obbligatori.
3. Schemi e Registro di sistema - Selezionare un formato, includere le regole di compatibilità.
4. Outbox/CDC: per ogni produttore, definire il meccanismo di pubblicazione dei fatti.
5. Partizionamento - Seleziona le chiavi e valuta le chiavi calde/ridisegnazione.
6. Idempoted: modello di deduplo + transazionalità dei consumatori.
7. Proiezioni - Definite i modelli materializzati e gli aggiornamenti SLA.
8. Tracciabilità, lame, DLQ, alert.
9. Sicurezza/PII: classificazione dei dati, crittografia, ACL.
10. Hyde sull'evoluzione: politica di versione, deprecato, dual-write per le migrazioni.

Assegno foglio di produzione

• Ogni evento ha «event _ id», «trace _ id», «occurred _ at», «partition _ key».
• Schemi nel registro, sono attivati i controlli di compatibilità.
• Idampotenza dei consumatori implementata e testata.
• DLQ/parcheggio lot e alert configurati per errori di pubblicazione/consumo.
• Le proiezioni vengono reindirizzate dal cavo (replay) con un tempo accettabile.
• Accesso limitato al PII; payload minimi nel nucleo.
• Le SLA sono misurate e visibili sui dashboard.
• Esiste un piano per la migrazione delle versioni degli eventi e delle finestre di deprecazione.

FAQ

Cosa è diverso dall'EDC?
Il nucleo non è solo un broker, ma anche un contratto di eventi, regole di ordine/idampotenza, processi di evoluzione e osservazione.

È possibile costruire solo su CDC?
Il CDC è adatto per le integrazioni/migrazioni, ma gli eventi di dominio sono più chiari e più stabili per i cambiamenti del database.

E la coerenza?
Accettiamo eventual consistency e progettiamo i processi UX sotto (indicatori di aggiornamento, retrai, compensi).

Quando hai bisogno di exactly-once?
Raramente, quando il raddoppio è strettamente inaccettabile e impossibile da compensare. Più spesso è sufficiente at-least-once + idampotenza.

Totale

Il core Event-Driven trasforma il flusso di fatti aziendali in una base di sistema affidabile. I contratti chiari, la disciplina di consegna e l'osservabilità forniscono scalabilità, sostenibilità e velocità di evoluzione - senza le fragili connessioni sincronizzate e la tempesta di regressione in caso di cambiamenti.