Running one Kafka platform for many teams: topic naming, quotas, self-service provisioning, creation policies, metering and the shared versus dedicated cluster decision.
Designing topic names that survive reorganizations: hierarchical patterns by team or product, what to keep out of names, enforcing prefixes with ACLs and handling the fact that topics cannot be renamed.
Protecting tenants from each other: produce and consume byte rates, request percentage quotas, defaults versus per-user overrides, connection limits and monitoring throttled clients.
Letting teams create topics without tickets or chaos: disabling auto-creation, GitOps with Strimzi KafkaTopic and KafkaUser resources, review rules for partitions and retention, and ownership metadata.
Using broker-side policies to block bad topic configurations: naming patterns, minimum replication factor, retention limits, and testing policies before rolling them out.
Allocating Kafka platform costs to teams: per-principal throughput from quota metrics, storage per topic prefix, partition counts, and building a monthly showback report.
Deciding how many Kafka clusters to run: isolation and blast radius, quota limits, operating cost per cluster, compliance separation and cross-cluster sharing with MirrorMaker 2.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.