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…
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.
Apache Pulsar BookKeeper IO Remediation
Resolving cluster-wide write latency caused by bookie journal and ledger device contention, and restoring write quorum headroom.
Docker Image Build and Layer Caching Optimization
Restructuring Dockerfiles and CI caching so builds reuse layers properly, cutting pipeline time and image size across a large service estate.
ELK Stack Pipeline Architecture Redesign
Consulting engagement to redesign an ELK ingest architecture around buffered queues, ingest node pipelines, and schema standardization.
OpenSearch Multi-Tenant Search Architecture Design
Consulting engagement to design tenant isolation, index strategy, and query governance for OpenSearch serving thousands of customer tenants.
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.