1. Tenants and Namespaces

At the core of Pulsar’s multi-tenancy model are tenants and namespaces. A tenant is the highest level of organizational boundary within Pulsar, typically representing a department, team, or customer. Each tenant has unique configurations and can be administered independently.

Within each tenant, Pulsar provides namespaces, which allow further segmentation. Namespaces organize topics into logical groups, making it possible to set policies at a granular level. Policies like quotas, time-to-live (TTL) for messages, and backlog retention can all be applied at the namespace level, offering flexibility and fine control over resource allocation.

2. Topic Segmentation

Topics are the fundamental data streams in Pulsar and are created within namespaces. Each topic inherits the policies set at the tenant and namespace levels, ensuring that each tenant has isolated, well-defined topics. This segmentation allows for organized access control and enables each tenant to operate independently.

To understand this in depth, refer to the post Understanding Apache Pulsar Topics: A Deep Dive into Naming Conventions.

3. Authentication and Authorization

Multi-tenancy demands stringent authentication and authorization controls, especially when dealing with sensitive data from multiple sources. Pulsar supports several authentication mechanisms, such as TLS, OAuth 2.0, and JWT tokens, to verify user identities. These security measures operate at the tenant level, making it easy to separate permissions between tenants.

Additionally, Pulsar offers role-based access control (RBAC), allowing fine-grained permission settings on read, write, and management operations. This ensures that only authorized users have access to specific tenants, namespaces, and topics.

4. Resource Isolation and Quotas

One of Pulsar's strongest features is its ability to apply quotas on resources within namespaces. Quotas limit the amount of storage, message retention, and message rates per tenant, preventing one tenant from overusing resources at the expense of others. Pulsar also enables dispatch throttling to manage bandwidth usage, preventing high usage by one tenant from impacting the performance of others.

5. Broker and Storage Isolation

Pulsar allows organizations to achieve both logical and physical isolation. By running in a geo-replicated cluster, specific tenants can have their data spread across multiple regions, while others may remain localized. Pulsar also supports dedicated clusters for tenants, providing even greater isolation by assigning specific broker resources.

6. Monitoring and Metrics

Effective multi-tenancy relies on real-time insights. Pulsar provides monitoring and metrics at every level — from tenants to namespaces to topics. This visibility makes it easy for admins to ensure fair resource usage and quickly resolve tenant-specific issues.

7. Load Balancing

Pulsar’s intelligent load balancing helps distribute topics and partitions across brokers, ensuring that resources are shared fairly among tenants. This prevents any single tenant from consuming excessive resources and ensures reliable performance across the board.

Conclusion

Apache Pulsar’s multi-tenancy features provide a scalable, secure, and efficient solution for organizations supporting multiple teams or customers. With its robust tenant, namespace, and topic structure, coupled with advanced authentication, resource quotas, and monitoring, Pulsar empowers organizations to manage data streaming across diverse users with ease and control. Whether it’s for internal departments or external clients, Pulsar's multi-tenancy framework offers the flexibility and isolation needed to maintain efficient operations.

For an in-depth comparison and insights on why Apache Pulsar may be a better fit for your organization than Kafka, download our comprehensive white paper Decoding Kafka Challenges: Addressing Common Pain Points in Kafka Deployments Whitepaper.

The Anatomy of a Pulsar Topic

A Pulsar topic follows this format:

persistent://tenant/namespace/topic-name

This three-level hierarchy isn't just for show – it's a powerful feature that enables better organization and control of your messaging infrastructure. Let's break down each component:

1. Persistence Prefix

The persistent:// prefix indicates that messages will be durably stored. For scenarios where persistence isn't needed, you can use non-persistent:// instead. This choice affects how Pulsar handles your messages and their storage.

2. Tenant

The tenant represents the highest level of isolation in Pulsar. Think of it as your organization's private space. For example, if your company is called Acme, you might use acme-corp as your tenant name.

3. Namespace

Namespaces provide logical grouping within a tenant. They're perfect for separating different departments, environments, or regions. For instance, you might have namespaces like marketing, production, or us-east.

4. Topic Name

The final component is your actual topic name, which describes the specific message stream, such as order-events or user-clicks.

Real-World Examples

Here are some practical examples of Pulsar topics:

persistent://trading-company/market-data/stock-quotes
persistent://ecommerce/order-processing/purchase-events
persistent://gaming-platform/us-west/player-statistics

Best Practices for Topic Organization

Consider these patterns when structuring your topics:

1. Regional Separation

   • persistent://company/us-west/events
   • persistent://company/eu-central/events

2. Environment Isolation

   • persistent://company/production/user-events
   • persistent://company/staging/user-events

3. Team-Based Organization

   • persistent://company/marketing/email-campaigns
   • persistent://company/sales/lead-tracking

This hierarchical structure not only provides clear organization but also enables granular control over authentication, authorization, and resource quotas at each level. Whether you're building a small application or a large-scale distributed system, understanding Pulsar's topic structure is key to effectively organizing your messaging architecture.