Architettura evento

Architettura evento (EDA)

1) Cosa è un evento e perché EDA

• scarsa connettività dei servizi,
• Scalabilità dei consumatori indipendentemente,
• repliche/ristrutturazioni di proiezioni,
• Un controllo trasparente.

L'EDA non annulla le API sincronizzate: le completa con le dipendenze di servizio incrociato in un livello asincrono.

2) Tipi di eventi

I domini sono fatti aziendali significativi (OrderPlaced, BonusGranted).
Integrazioni: snapshot/modifiche per sistemi esterni (UserUpdated, WalletBalanceChanged).
Tecnico: ciclo di vita e telemetria (Heartbeat, PipelineFailed).
Comandi (non eventi, ma vicini) - Istruzioni «fai X» (CapturePayment).

Raccomandazione: gli eventi di dominio sono primari; l'integrazione è formata da proiezioni per consumatori specifici.

3) Contratti eventi e schemi

Схема: Avro/Protobuf/JSON Schema + Schema Registry; strategia di compatibilità «BACKWARD» per l'evoluzione dei consumatori, «FULL» per temi critici.
CloudEvents (id, source, type, time, subject, dataconttype) è un titolo uniforme.
Metadati obbligatori: «event _ id» (ULID/UUID), «occurred _ at», «producer», «schema _ variante», «correlation _ id »/« causation _ id», «idempotency _ key».
Versioning: campi add-only, non rinominazione/rottura semantica; nuovi tipi - nuovi argomenti/tipi.

json
{
"type":"record","name":"PaymentCaptured","namespace":"events. v1",
"fields":[
{"name":"event_id","type":"string"},
{"name":"occurred_at","type":{"type":"long","logicalType":"timestamp-micros"}},
{"name":"payment_id","type":"string"},
{"name":"amount","type":{"type":"bytes","logicalType":"decimal","precision":18,"scale":2}},
{"name":"currency","type":"string"},
{"name":"player_id","type":"string"}
]
}

4) Spedizione, ordine e coerenza

At-least-once come default è necessario l'idipotenza dei processori.
Ordine: garantito all'interno di una partitura (Kafka) o di una coda (RabbitMQ), ma può essere violato durante i retrai; la chiave evento deve riflettere il granulo di dominio dell'ordine (ad esempio, «player _ id»).
Coerenza: per denaro/credito - solo attraverso riviste/sagra/compensi; Evitare la LWW.

Modello di lettura: le proiezioni e la cache possono essere eventual - Mostra l'aggiornamento in corso... e utilizza le strategie RNOT per percorsi rigorosi.

5) Outbox/Inbox и CDC

Outbox: il servizio scrive il fatto nel suo database e nella tabella outbox in una transazione il → worker pubblica nel bus.
Inbox: il consumatore salva «event _ id» con il risultato della deduplicazione.
CDC (Change Data Capture) - Flusso di modifiche dal database (binlog/WAL) al bus per creare le integrazioni senza modifiche all'applicazione.
Idempotency: elaborazione per «idempotency _ key »/« event _ id», non cambiare il mondo esterno prima della fissazione.

6) CQRS и Event Sourcing

CQRS: condividiamo il modello write e le proiezioni read le proiezioni sono costruite da eventi e possono rimanere indietro.
Event Source - Stato dell'aggregazione = compressione dei suoi eventi. Pro: controllo completo/repliche; contro: complessità delle migrazioni/diagrammi/snapshot.
Pratica: ES - non ovunque, ma dove la storia e i compensi sono importanti; CQRS è quasi sempre in EDA.

7) Saghe: orchestrazione e coreografia

Orchestrazione: il coordinatore invia squadre e attende eventi-risposte; facile da gestire per processi complessi (KYC→Deposit→Bonus).
Coreografia: i servizi rispondono agli eventi dell'altro; più semplice, ma più difficile da rintracciare.
Determinate sempre i compensi e le deadline dei passi.

8) Progettazione topologia (Kafka/RabbitMQ)

Kafka

Topic per evento di dominio: 'payments. captured. v1`, `players. verified. v1`.
Chiave di partizionamento: 'player _ id '/' wallet _ id', dove l'ordine è importante.
`replication. factor=3`, `min. insync. replica = 2 ', producer «acks = all».
Retention: in ordine di tempo (ad esempio 7-90 giorni) e/o compaction (ultimo stato chiave).
Topic per retry e DLQ con backoff.

RabbitMQ

Exchanges: `topic`/`direct`, routing key `payments. captured. v1`.
Per l'ampiezza fan-out - «topic» + più code; RPC/comandi sono code separate.
Quorum Queues per HA; TTL + dead-letter exchange per i retrai.

9) Osservabilità e SLO EDA

• End-to-end latency (occurred _ at → elaborato): p50/p95/p99.
• Lag/age: ritardo dei consumatori (Kafka consumer lag, Rabbit backlog age).
• Throughput pubblicazione/elaborazione.
• DLQ-rate e la percentuale di ripetizioni.
• Successo delle transazioni aziendali (ad esempio, «deposito confermato da 5s»).

• Correlazione degli eventi attraverso trace _ id/' correlation _ id '(OTEL).
• Varianti (exemplars) da metriche di pista.
• Dashboard «Producer→Broker→Consumer» con i burn-rate alert.

10) Repliche, retini e backfill

Repliche per la ricostruzione delle proiezioni/correzioni dei bagagli: correte verso una nuova proiezione/neimspace, quindi spostate la lettura.
Requisiti legali/aziendali (GDPR/PCI); campi sensibili - Cifrare e/o toccare.
Backfill: argomenti/code usa e getta, limiti RPS chiari per non soffocare la prua.

11) Sicurezza e compliance

TLS in-transit, per clienti interni.
Autorizzazione per-topic/per-exchange ACL; multitenancy tramite namespace/vhost.
PII - Ridurre al minimo i campi nell'evento; invelope metadati separatamente, carichi di lavoro utili da crittografare se necessario.
Controllo dell'accesso agli eventi, disabilitazione delle chiavi «tutte potenti».
Criteri di rimozione e di rimozione (GDPR) - Memorizzare i riferimenti ai dati o tomstone eventi e rimuoverli nelle proiezioni.

12) Test EDA

Contract test - I consumatori valutano le aspettative dei circuiti (consumer-driven).
Test replay: analisi del campione storico attraverso un nuovo processore/versione dello schema.
Gli scenari Chaos - ritardo/perdita del broker, calo dei nodi, ritardo del consumatore di SLO rimangono entro.
Smoke in CI è una pipline breve end-to-end sui temi temporali.

13) Migrazione delle «integrazioni CRUD» EDA

1. Identificare i fatti di dominio.
2. Incorporare outbox nei servizi di origine.
3. Pubblicare gli eventi minimi di dominio e collegare 1-2 proiezioni.
4. Disattivare gradualmente le integrazioni sincroni a punti sostituendole con le sottoscrizioni.
5. Immettere Schema Registry e il criterio di compatibilità.
6. Espandere gli eventi con campi add-only astinenza solo attraverso nuovi tipi.

14) Anti-pattern

Eventi = «API DTO» (troppo grassi, dipendono dal modello interno) - distruggono i consumatori.
L'assenza di Schema Registry e la compatibilità sono integrazioni «fragili».
Pubblicare dal codice e scrivere nel database non è atomane (nessun outbox) - Perde eventi.
«Exactly-once ovunque» - prezzo elevato senza beneficio; meglio at-least-once + idampotenza.
Una chiave di partitura «universale» è una partitura calda.
Repliche direttamente nella proiezione prod - rompe le SLO in linea.

15) Assegno foglio di implementazione (0-45 giorni)

0-10 giorni

Definire gli eventi di dominio e le relative chiavi (granuli d'ordine).
Espandi Schema Registry e approva la strategia di compatibilità.
Aggiungi outbox/inbox a 1-2 servizi; Minimo CloudEvents-envelope.

11-25 giorni

Immettere retry/DLQ, backoff, idimpotenza dei processori.
Dashboard: lag/age/end-to-end; burn-rate alert.
Documentazione degli eventi (directory), owner's e processi di rievocazione degli schemi.

26-45 giorni

Repliche/ristrutturazione della prima proiezione; runbook replica e backfill.
Criteri di sicurezza (TLS, ACL, PII), retensioni, procedure GDPR.
Regolarmente chaos-e game-days per il broker e i consumatori.

16) Metriche di maturità

Il 100% degli eventi di dominio sono descritti e registrati.
Outbox/inbox copre tutti i produttori/notebook Tier-0/1.
SLO: p95 end-to-end latency e consumer lag entro gli obiettivi del 99%.
Repliche/Backfill sono realizzabili senza downtime; ci sono runbook verificati'e.
Versioning: nuovi campi senza astinenza; i vecchi consumatori non cadono.
Sicurezza: TLS+mTLS, ACL per topic, registri di accesso, politica PII/retensh.

17) Mini snippet

properties acks=all enable. idempotence=true max. in. flight. requests. per. connection=1 compression. type=zstd linger. ms=5

python if inbox. contains (event_id): return # dedup process (event) # side effects are deterministic inbox. commit(event_id)        # atomically with side-effect commit_offset()

• `queue: tasks` → on nack → DLX `tasks. retry. 1m '(TTL = 60s) restituisce a tasks; «5m/15m».

18) Conclusione

EDA trasforma l'integrazione in un flusso di fatti aziendali con contratti chiari e coerenza gestita. Costruisci le fondamenta: diagrammi + registro, outbox/inbox, chiavi d'ordine, elaboratori idropotenti, SLO e osservabilità, retensioni e repliche sicure. Allora gli eventi saranno la vostra «fonte di verità» da ridimensionare, gli analisti e le nuove fiffe - senza legami fragili e migrazioni notturne.