Hamburg Apache Kafka® Ecosystem Meetup by Confluent

Name: Replicating Schemas & Governing Kafka for Users Apache Kafka®Meetup
Start: 2026-10-21T16:00:00.000Z
End: 2026-10-21T18:00:00.000Z
Location: Amerigo-Vespucci-Platz 2

4.4•102 ratings

About us

This is an Apache Kafka® Ecosystem meetup, administered within Confluent’s Meetup Network. Attend these events to learn about Confluent, Apache Kafka®, Apache Flink®, and the wider data streaming ecosystem, including adjacent technologies like Apache Iceberg™.

Confluent Network Meetup Commitments:

Our meetups are free and ungated.
Our events provide a safe environment for learning and collaboration, backed by our Code of conduct and rules of engagement.
Talks are highly technical, and actionable for individual devs (Propose a talk: No speaking experience required!).
Events are organised in collaboration with the community*

*Help us plan the next event: The Confluent team is remote. Contact us (community@confluent.io) if you would like to speak, recommend a venue, or, more generally, become a local community organizer.

Confluent Community:

Join Confluent’s community slack
View all our global meetup groups
Access world-class learning courses and materials for free at Confluent Developer, where you can also earn professional data streaming certificates.

Apache Kafka®, Kafka®, Apache Flink®, Flink®, Apache Iceberg™, Iceberg™, and associated open source project names are trademarks of the Apache Software Foundation. The Apache Software Foundation has no affiliation with and does not endorse, or review the materials provided here or at any of our Meetups.

Featured event

Replicating Schemas & Governing Kafka for Users Apache Kafka®Meetup

Wed, Oct 21 · 6:00 PM CEST

Amerigo-Vespucci-Platz 2, Amerigo-Vespucci-Platz 2, 20457 Hamburg, Germany, Hamburg, HH, DE

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.