Future of MultiTenantFilter

21 views
Skip to first unread message

Robert Young

unread,
Mar 4, 2026, 6:25:23 PM (5 days ago) Mar 4
to kroxylicious-dev
Hi everyone,

Following some recent discussions in GitHub Issues[1], I wanted to open a broader conversation about the future of the MultiTenantFilter and our wider plans for tenant isolation within the project.

The MultiTenantFilter was one of our first filters and has served as a valuable proof-of-concept for tenant isolation. While it remains marked as "incubation/preview" and carries known limitations, including incomplete RPC coverage and no solution to Noisy Neighbour issues, users have picked it up and are using it in Production. I think we should support these users and give them clarity about the future of the topics that have manifested on their Kafka cluster.

I'm currently wondering about two directions: continuing to extend the existing filter versus shifting focus to the newer, code-generated EntityIsolationFilter[2].

A proposed strategy is:

Continued Support: We will continue to accept essential, low-risk enhancements (like the custom prefix PR) to ensure the MultiTenantFilter remains viable for existing workflows.

Explicit Migration Goals: We add requirements to the EntityIsolationFilter design to ensure it can support the naming patterns established by the MultiTenantFilter.

The End-Goal: We want to reach feature parity, at which point we will provide a defined migration path to help users transition from the MultiTenantFilter to the EntityIsolationFilter without disruption to existing Kafka topics. We would deprecate MultiTenantFilter for deletion at this point.

My hesitation here is that the EntityIsolationFilter is very early in development, is it too early to decide on a direction?

Best,

Robert Young
Kroxylicious Project Team

1. https://github.com/kroxylicious/kroxylicious/issues/3396
2. https://github.com/kroxylicious/design/pull/80

Sam Barker

unread,
Mar 4, 2026, 11:15:28 PM (5 days ago) Mar 4
to kroxylicious-dev
Thanks for brining this up Rob.

Replies inline. 

On Thursday, 5 March 2026 at 12:25:23 UTC+13 robert...@gmail.com wrote:
Hi everyone,

Following some recent discussions in GitHub Issues[1], I wanted to open a broader conversation about the future of the MultiTenantFilter and our wider plans for tenant isolation within the project.

The MultiTenantFilter was one of our first filters and has served as a valuable proof-of-concept for tenant isolation. While it remains marked as "incubation/preview" and carries known limitations, including incomplete RPC coverage and no solution to Noisy Neighbour issues, users have picked it up and are using it in Production. I think we should support these users and give them clarity about the future of the topics that have manifested on their Kafka cluster.
Its definitely cool to hear users have things in production, even if they come with a running with scissors warning ;-)

I'm currently wondering about two directions: continuing to extend the existing filter versus shifting focus to the newer, code-generated EntityIsolationFilter[2].

A proposed strategy is:

Continued Support: We will continue to accept essential, low-risk enhancements (like the custom prefix PR) to ensure the MultiTenantFilter remains viable for existing workflows.
Yes, definitely we don't have a better alternative yet. I am certainly supportive of contributions there.   

Explicit Migration Goals: We add requirements to the EntityIsolationFilter design to ensure it can support the naming patterns established by the MultiTenantFilter.
Yes, with caveats. I don't think we should be extending the scope of the EntityIsolationFilter to encompass all of what we think we need for multi tenant support - what ever that is - but a more limited option to ensure we can support or migrate existing topics. 

The End-Goal: We want to reach feature parity, at which point we will provide a defined migration path to help users transition from the MultiTenantFilter to the EntityIsolationFilter without disruption to existing Kafka topics. We would deprecate MultiTenantFilter for deletion at this point.
Maybe we should move the MultiTenantFilter out to the community gallery, I think it might still have some value as a technology demonstration.   

My hesitation here is that the EntityIsolationFilter is very early in development, is it too early to decide on a direction?

EntityIsolationFilter is only a partial replacement, for the goals of multi tenant anyway. We believe there is something more compositional to cover everything, but we haven't scoped that out really. However as a team we haven't really looked at the MultiTenantFilter in ages so marking it deprecated is probably more honnest.

Sam

Kroxylicious Project Team / Commonhaus Rep 
Reply all
Reply to author
Forward
0 new messages