EDA tools and ecosystem: from idea to catalog 🧰

Governance of events without tools is “policy on a Word document nobody updates.” This guide covers the concrete tools that turn good intentions into something that works in the real world.

The tool map 🗺️

    flowchart TD
  SPEC[Specifications<br/>AsyncAPI / CloudEvents] --> CAT[Catalog<br/>EventCatalog / Backstage]
  SCHEMA[Schema<br/>Avro / Protobuf / JSON Schema] --> SREG[Schema Registry<br/>Confluent / Apicurio / Glue]
  CAT --> OPS[Operations and deployment]
  SREG --> OPS
  OPS --> OBS[Observability<br/>OpenTelemetry / Kafka UI]
  

AsyncAPI: the specification for asynchronous APIs 📄

AsyncAPI is a specification standard for message-based APIs, similar to OpenAPI but for asynchronous systems. It allows you to describe formally:

• channels (topics, queues, exchanges) and the underlying broker;
• messages published and consumed, with payload schema;
• broker-specific bindings (Kafka, AMQP, MQTT, WebSocket, NATS, and so on).

 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: Orders Service
  version: '1.0.0'
channels:
  order-created:
    address: order-created
    messages:
      OrderCreated:
        payload:
          type: object
          properties:
            order_id:
              type: string
            customer_id:
              type: string
            amount:
              type: number
          required: [order_id, customer_id, amount]
operations:
  publishOrderCreated:
    action: send
    channel:
      $ref: '#/channels/order-created'

With AsyncAPI you can:

• generate navigable HTML documentation;
• generate code stubs for producers and consumers;
• validate messages against the spec in CI;
• publish the spec in the catalog.

Ecosystem tools: AsyncAPI Generator, AsyncAPI Studio (web playground), AsyncAPI CLI.

EventCatalog: a catalog humans can read 📚

EventCatalog is an open-source tool to create a navigable and searchable event catalog. Configuration is in Markdown + YAML frontmatter—no database, no dedicated server.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

catalog/
  events/
    OrderCreated/
      index.md         ← description, owner, version history
      schema.json      ← or schema.avsc, schema.proto
  services/
    orders-service/
      index.md         ← which events it produces and consumes
  domains/
    orders/
      index.md

Key features:

• visual graph of producer/consumer dependencies for each event;
• versioning with changelog;
• integration with AsyncAPI and schema registry;
• deployment as a static site (GitHub Pages, Netlify, Vercel).

Ideal for: teams starting to formalize the catalog and wanting something operational in a day, not in a quarter.

Backstage + AsyncAPI plugin 🏗️

Backstage is Spotify’s open-source developer portal. With the AsyncAPI plugin, it can serve the event catalog integrated with the service, component, and team catalog.

When it makes sense: if you already have Backstage or are building a full developer portal. For the event catalog alone, EventCatalog is lighter and faster to configure.

CloudEvents: the common envelope 📦

CloudEvents is a CNCF specification for the structure of events, independent of broker and cloud provider. It defines standard attributes for the envelope without imposing anything on the domain payload.

Required attributes:

• id: unique event identifier.
• source: URI identifying the producer (for example /orders-service/v1).
• specversion: CloudEvents spec version (currently 1.0).
• type: event type (for example com.example.orders.order.created).

Common optional attributes:

• time: ISO 8601 timestamp.
• datacontenttype: MIME type of the payload (for example application/json).
• subject: specific subject of the event (for example order-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.example.orders.order.created",
  "time": "2026-03-16T10:05:00Z",
  "datacontenttype": "application/json",
  "subject": "order-123",
  "data": {
    "order_id": "order-123",
    "customer_id": "cli-456",
    "amount": 99.90
  }
}

Native support in brokers and clouds:

• Azure Event Grid: CloudEvents as native format;
• AWS EventBridge: supports CloudEvents with integrated schema registry;
• Google Cloud Eventarc: CloudEvents as native format;
• Kafka: CloudEvents Kafka Protocol Binding (official CNCF binding).

When to adopt it: if you have cross-cloud events, want to reduce lock-in on envelope format, or want interoperability with tools and platforms that support CloudEvents natively.

OpenTelemetry: observability that connects the dots 🔭

OpenTelemetry is the CNCF standard for traces, metrics, and logs. In an event-driven system it is critical for:

• propagating the trace_id through events (in metadata/headers);
• correlating producer and consumer spans in a single distributed trace;
• connecting logs, metrics, and traces for a single asynchronous business flow.

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

  P->>K: event with traceparent: abc-001
  K->>C: same event
  C->>C: child span of abc-001
  note over C: visible in Jaeger/Tempo as part of the same trace
  

Minimal OTel setup:

• propagate the trace context in the message header (traceparent according to W3C Trace Context);
• use the OpenTelemetry Kafka instrumentation for the target language;
• export to Jaeger, Grafana Tempo, or the cloud provider’s OTel backend.

Without propagation of trace context in the event, every consumer span appears “orphaned” in the tracing system: you know that something happened, but not why or where it came from.

Tools for observing the broker 🖥️

Quick broker comparison 📊

A table is not a benchmark, but it helps start with the right questions:

Tooling ecosystem checklist ✅

• Have you chosen a format for event specifications (AsyncAPI)?
• Do you have a searchable and updated event catalog (EventCatalog, Backstage, or a synchronized wiki)?
• Is the catalog integrated with the schema registry?
• Have you adopted CloudEvents as a standard envelope (or do you have an internal format that is coherent and documented)?
• Is trace context propagation (OTel traceparent) implemented on producers and consumers?
• Do you have a broker observability tool (Kafka UI, Conduktor, or equivalent)?

Next steps 🚀

• For governance and review processes: see the governance guide.
• For schema evolution and compatibility: see the Schema Registry guide.
• For contract testing with AsyncAPI: see the testing guide.