Pulsar's multi-tenancy is real, but only if the namespace policies are designed deliberately
KubernetesZooKeeperTeams share the cluster without contending for storage or broker capacity, and new tenants onboard against a defined policy template rather than inheriting defaults. Isolation is enforced by policy ra…
Overview
Pulsar's tenant and namespace model supports genuine isolation between teams, with per-namespace quotas, retention, authorization, and rate limits. It only isolates as well as the policy design, and default policies isolate very little. AceMQ designs the structure and the policy set that goes with it.
Challenge
Shared clusters built without a namespace design end up with everything in one namespace under default policies. One team's unbounded retention consumes storage the whole cluster needs, one team's high-throughput topic saturates brokers shared with latency-sensitive workloads, and authorization is coarse enough that any team can consume any topic. Retrofitting isolation later requires moving topics, which requires coordinating every consumer.
Environment
Shared Apache Pulsar clusters on Kubernetes serving multiple internal teams or external tenants, often with geo-replication.
Approach
AceMQ maps tenants and namespaces onto real ownership and isolation boundaries rather than arbitrary groupings, then defines the policy set per namespace class — retention, quotas, rate limits, and authorization. Broker isolation groups and bundle distribution are used where workload separation must extend to the hardware.
Solution
- 1Tenant and namespace hierarchy mapped to ownership, data classification, and isolation requirements
- 2Per-namespace policy templates covering retention, backlog quota, message TTL, and deduplication
- 3Publish and dispatch rate limits sized per namespace class so one tenant cannot saturate shared brokers
- 4Authentication and authorization design with per-namespace roles and token or mTLS credentials per tenant
- 5Broker isolation groups and bundle assignment where noisy workloads must be separated at the hardware level
- 6Onboarding runbook and policy-as-code definitions so new tenants inherit the design instead of defaults
Outcome
Teams share the cluster without contending for storage or broker capacity, and new tenants onboard against a defined policy template rather than inheriting defaults. Isolation is enforced by policy rather than by convention.
Technologies
KubernetesZooKeeperRelated Use Cases
Apache Pulsar Cluster Sizing and Architecture Assessment
Sizing brokers, bookies, and metadata for a Pulsar deployment against real throughput, retention, and durability requirements.
Apache Pulsar Backlog Quota and Producer Throttling Support
Diagnosing producers blocked by backlog quota enforcement when a slow or abandoned subscription prevents the backlog from clearing.
Need Apache Pulsar Architecture Guidance?
AceMQ's senior Apache Pulsar engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.