Stephane Derosiaux

You call producer.send() or consumer.poll(). On the wire, that one line is never a simple request: a handshake, a metadata fetch, version negotiation, then a Produce or a Fetch, plus the group coordination, heartbeats, and offset commits behind a consumer. All negotiated across protocol versions (Kafka is strict about backward and forward compatibility). Your logs don't show this. Kafka UIs show only the records. How do you see the protocol exchange itself? You don't. That's where the worst bugs hide: a full handshake on every record, an OffsetCommit after every message, a consumer-group rebalance storm, a producer still talking to a stale leader. To see it, we put a protocol tap between client and brokers, no SDK instrumentation, no code change, and decode the frames live. It works the same whatever client speaks them (Java, Go, Python, librdkafka, Kafka Streams, Flink, etc.), because the protocol is the contract. The demo uses Kapture UI (open-source) to filter the protocol stream, flag the anti-patterns as they appear, and fix your clients. By attending this session, your contact information may be shared with the sponsor for relevant follow up for this event only.

As an experiment, we've forked Kafka to introduce infinite partitions, topic views, multi-tenancy at the core and more. We want to share what we tried, what failed, what was more complex than expected, and how to deal with Kafka internals. At Conduktor, we've spent years building and running an enterprise Kafka proxy so we are we've come to master the Kafka protocol. Come join this geeky session if you dare!

Can LLMs play chess or not? In this talk, we use Kafka Queues (KIP‑932) to orchestrate agents playing chess without worrying about topic sprawl, partition limits, or LLM latency (which wrecks real‑time pipeline performance). We build Multiverse Chess: the white player is a share group that processes games in parallel and responds across many simultaneous boards. Its challengers (expert, random, greedy, troll, etc.) reply as soon as white plays. We track queue depth, per‑move latency, and scale to stress-test the system. This is a fun, technical demo of how Kafka Queues scale agentic workflows without partitioning issues. It shows how autonomous agent systems will rely on streaming platforms to manage LLM latency and operate effectively at scale.

Kafka is fast, but lag is everywhere. Data falls behind, consumers can’t keep up, and alerts keep firing. The usual reaction? Blame Kafka. The real issue? Kafka does exactly what it’s built to do: decouple producers and consumers. Lag isn’t a bug, it’s a side effect. Tracking offsets won’t save you. The real problem is time lag: the gap between when data is produced and when it’s actually processed. Consumer rebalances, inefficient commits, slow APIs, and bad scaling decisions all make it worse. Little’s Law predicts when lag will spiral, but most teams ignore it. This talk breaks down what’s really happening when Kafka "falls behind", why, and what you can do about it. Batching, commit strategies, parallel consumption, dropping messages, many options are available. Start controlling lag before it controls you.