Many teams adopt event-driven architecture to enable loose coupling and faster integration across applications. Over time, multiple teams start producing and consuming shared events through Kafka topics exposed using IBM Event Endpoint Management (EEM). However, one recurring challenge is safely evolving event contracts without breaking existing consumers.

In practice, producers often update schemas independently. Consumers may discover incompatible changes only after deployment. To avoid this risk, teams sometimes create duplicate topics or avoid evolving events entirely. This leads to catalog fragmentation and reduced reuse.

In this blog, I will show how combining AsyncAPI contracts with Event Endpoint Management helps detect breaking changes early and provides visibility into impacted consumers. This approach improves confidence in event evolution and supports safe event reuse.

Understanding the Problem: Schema Changes Without Impact Visibility

Consider a topic exposed through Event Endpoint Management:

Topic: user-profile-updated

Version 1 schema:

{

  "userId": "string",

  "email": "string",

  "name": "string"

}

A producer later updates the schema:

{

  "userId": "string",

  "primaryEmail": "string",

  "name": "string"

}

Here, the field email was renamed to primaryEmail. Structurally, the schema may still be valid, but existing consumers expecting email may fail.

Without visibility into which applications depend on this topic, the producer cannot assess the impact of this change.

Using AsyncAPI to Define Event Contracts

AsyncAPI provides a standard way to describe event contracts, including channels (topics), message formats, and payload structure.

Example AsyncAPI snippet:

channels:

  user-profile-updated:

    subscribe:

      message:

        payload:

          type: object

          properties:

            userId:

              type: string

            email:

              type: string

            name:

              type: string

This makes the event contract explicit and version-controlled.

When changes occur, we can compare AsyncAPI definitions to identify potential breaking changes.

Using Event Endpoint Management to Identify Consumers

IBM Event Endpoint Management provides visibility into applications that have subscribed to exposed event sources. This improves transparency and helps teams identify which registered consumers may be affected when evolving an event contract.

Example:

Event Source: user-profile-updated

Subscribed Applications:

  billing-service

  analytics-service

  notification-service

This information helps answer key questions:

• Which applications depend on this event?
• Which teams need to be informed about changes?
• Which consumers may need to migrate to a new version?

This visibility is critical for safe event evolution.

Detecting Breaking Changes Using Schema Comparison

We can compare previous and new AsyncAPI payload definitions programmatically.

Example Python snippet:

old_fields = {"userId", "email", "name"}

new_fields = {"userId", "primaryEmail", "name"}

removed_fields = old_fields - new_fields

if removed_fields:

    print("Breaking change detected:", removed_fields)

Output:

Breaking change detected: {'email'}

This allows us to detect risk early and take appropriate action.

How This Improves Event Governance

By combining AsyncAPI contracts and Event Endpoint Management, we can:

• Detect contract changes before or immediately after deployment
• Identify impacted consumers using catalog visibility
• Communicate changes clearly to dependent teams
• Support controlled migration to newer contract versions

This reduces the need for duplicate topics and improves trust in shared event contracts.

Conclusion and Next Steps

Creating duplicate topics to avoid risk leads to catalog fragmentation and reduces the overall value of event reuse. This can also become difficult to manage as the number of topics grows, making the event catalog harder to navigate and maintain. Event-driven systems benefit from stable and well-defined event contracts that can evolve in a controlled and predictable way. AsyncAPI helps define event contracts clearly and manage their evolution through version control, while Event Endpoint Management provides visibility into applications that have subscribed to exposed event sources. Together, they improve transparency and help teams evolve events more confidently.

You can start by:

• Defining event contracts using AsyncAPI and managing them in version control

• Publishing and exposing events through Event Endpoint Management

• Reviewing contract changes as part of your version control workflow before evolving event schemas

• Using Event Endpoint Management to view subscribed applications and improve visibility into which registered consumers may be affected by changes

In the next blog, I will explore how Kafka Admin APIs and runtime consumption metrics can be used to analyze topic usage and identify unused or duplicate topics. This helps maintain a clean and manageable event catalog in Event Endpoint Management and supports scalable event-driven architecture.