Request: Roadmap / KIP-932 (Kafka Queues, Share Consumer) Support in Spring Cloud Stream Kafka Binder

[iguissouma]

Hello,
I’d like to ask about the roadmap for Spring Cloud Stream, specifically regarding support for KIP-932 (Kafka Queues, share consumers).

Context:

• Kafka 4.0+ has introduced KIP-932 (“share groups”) in early access / preview form.
• Spring for Apache Kafka (spring-kafka 4.x) already provides experimental support for share consumers (e.g. ShareConsumerFactory, ShareKafkaMessageListenerContainer).
• Many of us using Spring Cloud Stream with the Kafka binder would benefit from being able to experiment with (and later adopt) the new share group / queue consumption model.

Questions:

• Is there a public roadmap for Spring Cloud Stream (Kafka binder in particular)?
• Are there plans or timelines to integrate support for KIP-932 / share consumers once the feature stabilizes in Kafka and Spring Kafka?

Why this matters:

KIP-932 opens new scaling and consumption models (queue-like semantics, cooperative multi-consumer partition consumption) that could be very valuable in microservice architectures using Spring Cloud Stream.

---

Looking forward to your guidance on the roadmap and how/when KIP-932 might be supported.

[sobychacko]

@iguissouma Share Consumer support is not in the scope for the upcoming Spring Cloud Stream 5.0.x release. Our goal at this point is to stabilize this support in Spring Kafka and lay the foundations properly. Once that is done, we could start thinking about what should be the queue support in Spring Cloud Stream. Most likely in a 5.1.x release. While that may not be the answer you are looking for, that could be a good thing, because by that time, this feature will be out of preview mode and fully ready for production. There is not a strict public roadmap for the current 5.0.x release, but you can get a sense of where things are from the commits and issues in the binder (via core Spring Cloud Stream). If you have any specific design ideas for this feature in the binder, we are all ears and we can probably iterate on it here. Thanks for bringing this up!