Pulsar's multi-tenancy is real, but only if the namespace policies are designed deliberately

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

• Tenant and namespace hierarchy mapped to ownership, data classification, and isolation requirements
• Per-namespace policy templates covering retention, backlog quota, message TTL, and deduplication
• Publish and dispatch rate limits sized per namespace class so one tenant cannot saturate shared brokers
• Authentication and authorization design with per-namespace roles and token or mTLS credentials per tenant
• Broker isolation groups and bundle assignment where noisy workloads must be separated at the hardware level
• Onboarding runbook and policy-as-code definitions so new tenants inherit the design instead of defaults

Outcome

Technologies