Thanks Lucas for the KIP. The KIP is already in very good shape and covers
the edge cases. I still have a few questions and considerations I’d like to
share.

AS01:  Are Assignment topology (defined in KIP-1071) and the Description
topology (defined in KIP-1331) guaranteed to be consistent views of the
same logical topology, or can they drift? Are we guaranteeing that every
assignment we surface references only nodes/topics present in the current
description topology, or can operators see combinations that don’t line up?

AS02: I'm cusrious about the rationale or empirical data behind the 350 KB
default (e.g., based on observed real-world topologies)? Also the KIP says
the broker measures topology size and rejects oversized payloads with
TOPOLOGY_DESCRIPTION_TOO_LARGE. Should the Streams client attempt a
best-effort pre-check of the serialized size to avoid repeated failing
pushes and log a clearer local error? Or is the intent to keep the client
simple and rely entirely on the broker response + plugin behavior for this
case?

AS03: Why do we introduce a separate Admin-side POJO instead of reusing
TopologyDescription from the Streams API—for dependency/semantic reasons?
And how do we plan to keep the two representations in sync?

AS04: Somewhat related to AS01.... In practice we’ve seen that because
members and assignments change so dynamically, a user may see different
assignments or members over just a few seconds, or a member with a specific
memberId may disappear entirely. Having the topology visible might help
users understand what’s going on—but it could also make things more
confusing, depending on the situation.

AS05: I assume that even with a single plugin, multiple downstream systems
can still benefit from it (the plugin can of course fan out to multiple
downstream systems). Am I right?

Thanks,
Alieh



On Mon, May 4, 2026 at 11:39 AM Lucas Brutschy via dev <[email protected]>
wrote:

> Hi all,
>
> I would like to start the discussion on KIP-1331. The idea is to
> optionally make a topology description available to the broker, in the
> spirit of KIP-714. Looking forward to your feedback!
>
>
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1331*3A*Streams*Group*Topology*Description*Plugin__;JSsrKysr!!Ayb5sqE7!sxqGDUcjOzRpt9Gk0jE1XnVSit-FZMIihk2UsXWUI0jmdYK2nTcO1hP-9WiW5sLBMw8amIUxG2PGvhdRhok$
>
> Best,
> Lucas
>

Reply via email to