Event-Driven Architecture

Entra nell'ecosistema EDA: la sidebar ti guida dalla mappa mentale a un percorso strutturato — Visual, contratto CloudEvents, codice server/client e cicche del senior.

Approfondimento

Definizioni, contesto e collegamenti tra concetti — leggi prima del palcoscenico interattivo se parti da zero.

Cos’è un’architettura event-driven

Un’architettura event-driven (EDA) organizza il sistema attorno al fatto che qualcosa è successo: un ordine è stato piazzato, un pagamento è fallito, un profilo è cambiato. Questi fatti viaggiano come messaggi (eventi) tra processi, spesso attraverso un broker o un bus, invece di incatenare chiamate sincrone ovunque.

Il publisher emette un evento senza sapere chi reagirà; i consumer si iscrivono e applicano la propria logica. Il vantaggio principale è il disaccoppiamento: team diversi possono evolvere servizi in parallelo se il contratto dell’evento resta comprensibile e stabile.

L’EDA non è “solo Kafka”: è prima di tutto un modo di modellare i confini e i flussi. Puoi partire da un bus in-process, da code gestite, da notifiche HTTP, e crescere verso infrastrutture distribuite quando il dominio lo richiede.

Quando ha senso (e quando no)

Ha senso quando hai integrazioni multiple sullo stesso fatto di business, team che scalano su servizi diversi, o bisogni di audit e replay. Ha meno senso per un CRUD isolato senza integrazioni: lì l’overhead di code, schema e osservabilità spesso non ripaga.

Ogni scelta di asincronia introduce consistenza eventuale: il dato letto può essere leggermente indietro rispetto all’ultima scrittura. Se il prodotto promette “immediato ovunque”, devi progettare UX e SLO di freschezza con attenzione.

CloudEvents e glossario minimo

In questo modulo usiamo CloudEvents 1.0 come contenitore standard: campi come `specversion`, `type`, `source`, `id`, `time` e `data` rendono gli esempi confrontabili tra pagine e con strumenti reali (Knative, SDK ufficiali, gateway HTTP).

Termini ricorrenti: broker (smista messaggi), topic/coda (canali logici), consumer group (Kafka: stesso gruppo condivide il lavoro per partizione), publisher/subscriber (chi emette / chi riceve), dead letter queue (coda di messaggi falliti), outbox (pattern per pubblicare in modo affidabile insieme alla transazione DB).

Correlation ID e Trace ID servono a ricostruire una storia distribuita nei log: senza di essi, il debugging tra cinque microservizi diventa indovinare.

Palcoscenico

Order API

Pubblica `order.placed`

Event Bus

Notifiche

Fatturazione

Magazzino

Messaggio replicato in parallelo verso consumer indipendenti

Diagramma

Contratto e codice

Schema JSON basato su CloudEvents 1.0, poi snippet server e client.

{
  "specversion": "1.0",
  "source": "/orders-service",
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "time": "2026-05-13T12:00:00.000Z",
  "datacontenttype": "application/json",
  "type": "com.example.hub.eda.map",
  "data": {
    "module": "eda",
    "version": 1,
    "sections": ["core", "patterns", "reliability", "tradeoffs", "labs"]
  }
}