Tool ed ecosistema EDA: dall'idea al catalogo 🧰

La governance degli eventi senza strumenti è “policy su un documento Word che nessuno aggiorna”. Questa guida copre i tool concreti che trasformano le buone intenzioni in qualcosa che funziona nel mondo reale.

La mappa degli strumenti 🗺️

    flowchart TD
  SPEC[Specifiche<br/>AsyncAPI / CloudEvents] --> CAT[Catalogo<br/>EventCatalog / Backstage]
  SCHEMA[Schema<br/>Avro / Protobuf / JSON Schema] --> SREG[Schema Registry<br/>Confluent / Apicurio / Glue]
  CAT --> OPS[Operatività e deploy]
  SREG --> OPS
  OPS --> OBS[Osservabilità<br/>OpenTelemetry / Kafka UI]

AsyncAPI: la specifica per le API asincrone 📄

AsyncAPI è uno standard di specifica per API basate su messaggi, analogo a OpenAPI ma per sistemi asincroni. Permette di descrivere formalmente:

i canali (topic, queue, exchange) e il broker sottostante;
i messaggi pubblicati e consumati, con schema del payload;
i binding specifici per broker (Kafka, AMQP, MQTT, WebSocket, NATS, ecc.).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


asyncapi: '3.0.0'
info:
  title: Ordini Service
  version: '1.0.0'
channels:
  ordine-creato:
    address: ordine-creato
    messages:
      OrdineCreato:
        payload:
          type: object
          properties:
            ordine_id:
              type: string
            cliente_id:
              type: string
            importo:
              type: number
          required: [ordine_id, cliente_id, importo]
operations:
  publishOrdineCreato:
    action: send
    channel:
      $ref: '#/channels/ordine-creato'

Con AsyncAPI puoi:

generare documentazione HTML navigabile;
generare stub di codice per producer e consumer;
validare i messaggi rispetto alla spec in CI;
pubblicare la spec nel catalogo.

Tool dell’ecosistema: AsyncAPI Generator, AsyncAPI Studio (playground web), AsyncAPI CLI.

EventCatalog: il catalogo leggibile dagli umani 📚

EventCatalog è uno strumento open source per creare un catalogo di eventi navigabile e ricercabile. La configurazione è in Markdown + frontmatter YAML — nessun database, nessun server dedicato.

catalog/
  events/
    OrdineCreato/
      index.md         ← descrizione, owner, version history
      schema.json      ← o schema.avsc, schema.proto
  services/
    ordini-service/
      index.md         ← quali eventi produce e consuma
  domains/
    ordini/
      index.md

Funzionalità chiave:

grafo visuale delle dipendenze producer/consumer per ogni evento;
versioning con changelog;
integrazione con AsyncAPI e schema registry;
deployment come sito statico (GitHub Pages, Netlify, Vercel).

Ideale per: team che iniziano a formalizzare il catalogo e vogliono qualcosa di operativo in un giorno, non in un trimestre.

Backstage + plugin AsyncAPI 🏗️

Backstage è il developer portal open source di Spotify. Con il plugin AsyncAPI, può servire il catalogo degli eventi integrato con il catalogo dei servizi, dei componenti e dei team.

Quando ha senso: se hai già Backstage o stai costruendo un developer portal completo. Per il solo catalogo eventi, EventCatalog è più leggero e più rapido da configurare.

CloudEvents: l’envelope comune 📦

CloudEvents è una specifica CNCF per la struttura degli eventi, indipendente dal broker e dal cloud provider. Definisce attributi standard per l’envelope — senza imporre nulla sul payload di dominio.

Attributi obbligatori:

id: identificatore univoco dell’evento.
source: URI che identifica il producer (es. /orders-service/v1).
specversion: versione della spec CloudEvents (attualmente 1.0).
type: tipo dell’evento (es. com.esempio.ordini.ordine.creato).

Attributi opzionali comuni:

time: timestamp ISO 8601.
datacontenttype: tipo MIME del payload (es. application/json).
subject: soggetto specifico dell’evento (es. ordine-123).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


{
  "specversion": "1.0",
  "id": "evt-7f3a9c",
  "source": "/orders-service/v1",
  "type": "com.esempio.ordini.ordine.creato",
  "time": "2026-03-16T10:05:00Z",
  "datacontenttype": "application/json",
  "subject": "ordine-123",
  "data": {
    "ordine_id": "ordine-123",
    "cliente_id": "cli-456",
    "importo": 99.90
  }
}

Supporto nativo su broker e cloud:

Azure Event Grid: CloudEvents come formato nativo;
AWS EventBridge: supporta CloudEvents con schema registry integrato;
Google Cloud Eventarc: CloudEvents come formato nativo;
Kafka: CloudEvents Kafka Protocol Binding (binding ufficiale CNCF).

Quando adottarlo: se hai eventi cross-cloud, vuoi ridurre lock-in sul formato dell’envelope, o vuoi interoperabilità con tool e piattaforme che supportano CloudEvents nativamente.

OpenTelemetry: osservabilità che connette i puntini 🔭

OpenTelemetry è lo standard CNCF per traces, metrics e logs. In un sistema event-driven è critico per:

propagare il trace_id attraverso gli eventi (nei metadata/header);
correlare le span di producer e consumer in un unico trace distribuito;
collegare log, metriche e trace per un singolo flusso di business asincrono.

    sequenceDiagram
  participant P as Producer (trace: abc)
  participant K as Kafka
  participant C as Consumer

  P->>K: evento con traceparent: abc-001
  K->>C: stesso evento
  C->>C: span figlio di abc-001
  note over C: visibile in Jaeger/Tempo come parte dello stesso trace

Setup minimo con OTel:

propaga il contesto di trace nell’header del messaggio (traceparent secondo W3C Trace Context);
usa la Kafka instrumentation di OpenTelemetry per il linguaggio target;
esporta verso Jaeger, Grafana Tempo, o il backend OTel del cloud provider.

Senza propagazione del trace context nell’evento, ogni span di consumer appare “orfano” nel sistema di tracing: sai che qualcosa è successo, ma non sai perché né da dove è arrivato.

Tool per osservare il broker 🖥️

Tool	Tipo	Note
Kafka UI	Open source	Web UI per topic, consumer group, messaggi
Redpanda Console	Open source	Compatibile Kafka, UI moderna
Conduktor	Commerciale (free tier)	Kafka ops + governance integrata
KPOW	Commerciale	Team-oriented Kafka management
Confluent Control Center	Commerciale / incluso	Piattaforma Confluent enterprise

Confronto rapido tra broker 📊

Una tabella non sostituisce un benchmark, ma aiuta a partire con le domande giuste:

Broker	Delivery	Ordering	Replay	Hosting	Note
Apache Kafka	At-least-once / EOS	Per partizione	✅	Self / Cloud	Standard de facto per streaming
RabbitMQ	At-least-once	Per queue	❌ (nativamente)	Self / Cloud	AMQP, ottimo per task queue
AWS SQS	At-least-once	Con SQS FIFO	❌	Managed AWS	Semplicità operativa su AWS
AWS SNS	At-least-once	No	❌	Managed AWS	Fan-out, integrato con SQS/Lambda
AWS Kinesis	At-least-once	Per shard	✅	Managed AWS	Stream analytics su AWS
Google Pub/Sub	At-least-once	Con Ordering Key	⚠️ Seek limitato	Managed GCP	Scalabile, buona integrazione GCP
Azure Service Bus	At-least-once	Sessioni	❌	Managed Azure	Dead-letter, sessioni, feature avanzate
NATS JetStream	At-least-once / Exactly-once	Per stream	✅	Self / Cloud	Leggero, latenza molto bassa
Redpanda	At-least-once / EOS	Per partizione	✅	Self / Cloud	Compatibile API Kafka, C++, performance

Checklist ecosistema tool ✅

Hai scelto un formato per le specifiche degli eventi (AsyncAPI)?
Hai un catalogo eventi ricercabile e aggiornato (EventCatalog, Backstage, o wiki sincronizzata)?
Il catalogo è integrato con lo schema registry?
Hai adottato CloudEvents come envelope standard (o hai un formato interno coerente e documentato)?
La propagazione del trace context (OTel traceparent) è implementata su producer e consumer?
Hai un tool di osservabilità del broker (Kafka UI, Conduktor, o equivalente)?

Prossimi passi 🚀

Per governance e processi di review: vedi la guida di governance.
Per schema evolution e compatibilità: vedi la guida su Schema Registry.
Per testing dei contratti con AsyncAPI: vedi la guida su testing.

Ultimo aggiornamento il 21 marzo 2026

Sicurezza