Replicating Schemas & Governing Kafka for Users Apache Kafka®Meetup

Join us for an Apache Kafka® meetup in Hamburg from 18:00 hosted by Vattenfall & Conduktor!

Agenda:
6:00pm: Doors open
6:00pm – 6:30pm: Food/Drinks and networking
6:30pm - 7:15pm: The Bytes Arrived, the Schema Didn't: Replicating Schemas across cluster - Marcel Radusch with Vattenfall
7:15pm - 8:00pm: Governing Kafka for Users, Agents and Applications - Fabian Schmitzer with Conduktor
8:00pm - 9:00pm: Additional Q&A and Networking

Title of Talk 1: The Bytes Arrived, the Schema Didn't: Replicating Schemas across clusters

Abstract: MirrorMaker 2 replicates your topics flawlessly, byte for byte, and your consumer in the target cluster still throws a deserialization error. The reason hides in the five bytes at the front of every record: a schema ID that is only meaningful in the registry that issued it. Worse, every Schema Registry starts handing out IDs at 1, so the same ID usually exists on the other side too, pointing at a completely unrelated schema.
Confluent's answer is Schema Linking, an Enterprise feature. This talk is about what you can build when that isn't an option.
I'll walk through a way, that keeps one Schema Registry per cluster holding its own schemas as writable and the peer's as read-only, with the original schema IDs preserved. The ingredients are all Community Edition. The payoff is a subject-naming trick that makes current clients resolve the right context with no configuration change at all.
Aimed at anyone running Kafka across more than one cluster.

Talk 2: Governing Kafka for Users, Agents and Applications

Abstract: Kafka clusters rarely serve one kind of client anymore. Developers explore topics, services produce and consume at scale, and more and more AI agents discover streams and act on them. These clients need different trust models, but most clusters handle all of them with the same ACLs and service accounts.

This talk separates what Apache Kafka offers natively (OAUTHBEARER/OIDC and mTLS identities, prefixed ACLs, quotas, topic creation configurations) from what requires surrounding components such as schema registries, proxies, or client-side serializers for validation, encryption, and masking. For each control we look at which layer it belongs in and what it costs in latency, operations, and developer effort.
We'll then focus on agents. They are non-deterministic, decide at runtime which topics to read, and usually act on behalf of a user, while Kafka typically only sees the agent's service account. Classic application ACLs don't cover that. We'll look at exposing curated data products instead of raw topics, keeping write access narrow, and passing user identity and trace context along so you can audit what an agent did. Expect concrete configurations, failure modes we've seen, and patterns you can apply within your enterprise architecture.