BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//sf26-agenda//EN
CALSCALE:GREGORIAN
METHOD:PUBLISH
BEGIN:VEVENT
UID:SESS-178@sf26-agenda
DTSTAMP:20261020T151709Z
DTSTART:20261105T001500Z
DTEND:20261105T010000Z
SUMMARY:Kafka Streams Needs Real Timers
LOCATION:Room 2012
DESCRIPTION:Hartmut Armbruster\n\nKafka Streams gives you punctuators: call
 backs 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 ef
 fects\, and remember to delete or reschedule it yourself. Every team that 
 needs cart abandonment\, session expiry\, SLA deadlines\, or delayed retri
 es eventually reinvents this pattern. Flink’s keyed TimerService solves 
 the same problem differently: register a one-shot timer for the current ke
 y and timestamp\, get an onTimer() callback for that exact key\, and let t
 he runtime handle deduplication\, deletion\, and dispatch. In Kafka Stream
 s you emulate timers; in Flink you ask for them. This talk compares the tw
 o models honestly: where Kafka Streams’ punctuators are simple and power
 ful\, where they break down\, and what bugs hide inside the common state-s
 tore-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 if per
 -key timeouts were treated as a runtime primitive rather than an applicati
 on-level workaround.
URL:https://sf26.rmoff.net/s/kafka-streams-needs-real-timers-178
END:VEVENT
END:VCALENDAR