Multi-Tenant Kafka Clusters

Commerce, Billing, and Analytics all need Kafka. Running a separate cluster for every team would give them independent environments, but it would also multiply maintenance, spare capacity, monitoring, and recovery work. A shared cluster can make better use of infrastructure and give teams a consistent platform.

Sharing introduces dependencies. An Analytics replay can compete with live order traffic. A broad permission grant can expose Billing data. A cluster upgrade affects several teams at once.

A multi-tenant design makes those dependencies explicit and controls them. This chapter explains how to define tenant boundaries, manage resources and access, and operate a shared platform over time. Examples assume Apache Kafka 4.3.1 in KRaft mode with authenticated TLS connections, StandardAuthorizer, and Kafka's default quota handling.