Kannika and EventCatalog: you can't recover what you never documented

Kannika and EventCatalog are partnering up. Here's why EDA governance and Kafka backup are two halves of the same problem.

Most teams building on Kafka discover their gaps in the same order. First it works. Then it grows. Then somebody asks a question nobody can answer.

"Which services consume this event?"

"What happens if we change this schema?"

"Can we get last Tuesday's data back?"

The first two questions are governance problems. The third is a recovery problem. They feel like separate concerns, owned by separate people, solved by separate tools. In practice they come from the same root cause: an event-driven architecture that grew faster than the discipline around it.

That is the short version of why Kannika and EventCatalog are now working together. We sat down with David Boyne, founder of EventCatalog, to talk about where the two sides meet.

‍

What is EventCatalog?

EventCatalog started about five years ago as an open source side project. David was introducing event-driven architecture on engineering teams and hit a problem that will sound familiar to anyone who has done the same.

"We were building events and we had no way to track the events or document events. It was just like, okay, we have 10 events, 20 events. I was thinking, how the hell are people keeping hold of these events if they just live in GitHub?"

, David Boyne

He open sourced the idea, went to work at AWS advocating for event-driven architectures, and found that large enterprises had exactly the same problem at a much larger scale. The project grew, turned into a business, and is now his full-time work.

‍

"EDA is five or ten years behind"

The thing that struck us most in the conversation was how closely David's view of the ecosystem matches ours, despite coming at it from a different angle.

"When you look at EDA in this space, documentation, governance, backup, retention, production data, all this kind of stuff, it feels like EDA is five or ten years behind the traditional REST industry. The traditional databases, the traditional APIs."

, David Boyne

That gap is why both of our products exist. Backup and restore for a relational database is a solved problem with decades of tooling and literature behind it. Backup and restore for Kafka is still something teams try to build themselves with Kafka Connect and S3 sinks, and then find out during an incident that they cannot restore from it. Documentation for a REST API has OpenAPI and a mature toolchain. Documentation for an event-driven system, for a long time, meant a Confluence page that went stale in a fortnight.

‍

The pattern is always the same: it works until it doesn't

Ask David when teams come to EventCatalog and the answer is scale:

"You have one event, five events, ten events, a hundred events. It comes to a point where you just can't manage that anymore. And then people always ask the questions, which is: what events do we have? Who's producing what? How can I change things? Breaking changes?"

, David Boyne

Early on, there is usually one person who holds the whole picture in their head. An integration architect, an EDA advocate, the person who pushed for this architecture in the first place. Ask them anything and you get an answer. That works, right up until the system outgrows one person's memory or that person leaves.

"Most people tend to be large enterprises, and they're in a mess. And they're in a mess because they have no idea what's going on. Because no one documented it. And no one thought about that."

, David Boyne

We see the identical curve on the resilience side. The first Kafka cluster is a pipeline. Data moves from A to B, retention is short, and if you lose an hour of messages you replay from source. Nobody writes a recovery plan for a pipeline. Then the workflows change. Events become the record of what happened rather than a transport mechanism for it. Teams start doing event sourcing, building projections, warehousing streams for analytics. The data becomes the asset.

Nobody makes a decision to cross that line. You just wake up one day on the other side of it.

‍

Design-time decisions with runtime consequences

Kafka's retention configuration is a design-time decision. Someone sets it once, based on assumptions about a workflow that may since have changed hands three times. There is no runtime safety net underneath it.

"It's really a lot of pressure onto the architect and the teams to figure out their data retention policies, and the importance of GDPR, and all that. It's very much a design-time requirement or thinking, rather than a runtime guarantee of: okay, well, we're going to do this anyway, and by the way, you'll have all this information backed up anyway."

, David Boyne

A well-governed catalog tells you which topics carry data the business cannot lose, who produces them, who consumes them, and what the retention policy is supposed to be. That is valuable, and most organisations do not have it. But it is documentation of intent. It does not stop somebody setting a retention value to a number with one fewer zero than they meant, and it does not bring the data back afterwards.

This is the same argument we make about replication. Replication faithfully copies your mistakes. It protects the service, not the data. Governance and replication are both necessary, and neither one is a recovery plan.

‍

What changes when AI agents read your architecture

Documentation used to be the thing one senior engineer nagged everyone about. That has shifted, and not for the reasons anyone predicted.

"If you document your architecture, you've got your topics, Kafka, streams, all this going on, why can't the agent have that context? Give an example of such a scenario: you make a pull request to a schema change. The agent knows if it's breaking or not, and the agent knows who the consumers are. The agent can then go tell the consumers, stop the pull request. Just because it's documented."

, David Boyne

Documentation has become machine-readable input rather than a courtesy to the next human. EventCatalog ships an MCP server for exactly this reason.

The resilience side of that story is less discussed and worth saying out loud. Agents that can read your architecture will eventually be agents that act on it, and they will make changes at a speed and volume that no review process fully catches. Retention changes, topic configuration, schema evolution. The blast radius of a bad automated change is larger than the blast radius of a bad human one, and it arrives faster. Point-in-time recovery is what makes that risk survivable.

‍

Where this partnership goes

David's framing of why he reached out in the first place is the one we would use too:

"There is a pie out there for EDA, and let's just make it bigger together."

, David Boyne

Practically, the two products sit next to each other cleanly. EventCatalog is where you describe your event-driven architecture: the domains, the services, the schemas, the ownership, the flows. Kannika Armory is what stands behind the topics in that catalog, backing them up to independent storage and restoring them to a point in time when something goes wrong.

If you are somewhere on this curve, a reasonable place to start is with three questions:

1. Can you list every topic carrying data your business cannot reconstruct from another source?
2. For each of those, do you know who produces it, who consumes it, and what its retention policy is?
3. When did you last restore one of them, end to end, and timed it?

If you cannot answer the first two, that is a documentation problem, and EventCatalog is a good place to fix it. If you cannot answer the third, that is what we build.

Most teams cannot answer any of them. That is not a criticism, it is just where the ecosystem is. As David put it, everyone feels the same pains and everyone is building their own solution. Both of us would rather they didn't have to.

Explore the Kannika Sandbox or book a demo to see what point-in-time recovery for Kafka looks like in practice.