Hartmut Armbruster

Kafka Streams gives you punctuators: callbacks that fire on an interval, per task. If you need a per-key timeout, you typically scan a state store, find whatever is due, trigger side effects, and remember to delete or reschedule it yourself. Every team that needs cart abandonment, session expiry, SLA deadlines, or delayed retries eventually reinvents this pattern. Flink’s keyed TimerService solves the same problem differently: register a one-shot timer for the current key and timestamp, get an onTimer() callback for that exact key, and let the runtime handle deduplication, deletion, and dispatch. In Kafka Streams you emulate timers; in Flink you ask for them. This talk compares the two models honestly: where Kafka Streams’ punctuators are simple and powerful, where they break down, and what bugs hide inside the common state-store-scan idiom. Then it sketches a first-class per-key timer API for the Kafka Streams Processor API: stream-time and wall-clock timers, automatic per-key serialisation, deletable one-shot registrations, and callbacks that fire for the key that registered them. The goal is not to turn Kafka Streams into Flink. It is to ask what Kafka Streams would look like…

Your Kafka Streams application just rebalanced. Again. Your Flink checkpoint is timing out. Again. Here's an uncomfortable truth: most stream processing applications don't operate at Uber scale. They handle thousands of events per second—complex joins, stateful aggregations, valid use cases—but nowhere near the volumes that justify the operational complexity we've accepted as normal. Yet we pay the full distributed systems tax anyway. Repartition topics doubling network I/O. Repeated serialization burning CPU cycles. Standby replicas sitting idle. State migration or restoration during deployments. And the human cost: specialized expertise that takes years to develop, expert teams that are expensive to build and painful to lose. We've normalized extraordinary inefficiency in the name of horizontal scalability that many applications will never need. But rethinking stream processing in 2026 doesn't mean "just use Postgres." In this talk, I'll share an early-stage exploration of a different approach. A framework that preserves the Kafka Streams DSL, borrows Flink's approach to exactly-once semantics, leverages Project Loom for high concurrency—and challenges a fundamental assumption…

Struggled with the complexity of designing Kafka Streams applications? Without sufficient up-front architecture work, it's all too easy to stumble into misunderstandings, rework, or outright failure. Although standards like UML and C4 model have guided software designs for years, stream processing has lacked a visual framework - until now. KSTD (Kafka Streams Topology Design) introduces an open standard and component library for describing and visualising Kafka Stream Topologies with Excalidraw. Simple principles ensure teams can keep diagrams simple yet include important details, build trust in their designs, and streamline the development lifecycle. You will learn how standardised diagrams support team alignment, and how KSTD fosters consistent and clear communication for Kafka Streams. Design up-front, avoid mistakes, save time, and build trust.