Pulsar was created from the ground up as a multi-tenant system. To support multi-tenancy, Pulsar has a concept of tenants. Tenants can be spread across clusters and can each have their own authentication and authorization scheme applied to them. They are also the administrative unit at which storage quotas, message TTL, and isolation policies can be managed.
The multi-tenant nature of Pulsar is reflected mostly visibly in topic URLs, which have this structure:
persistent://tenant/namespace/topic
As you can see, the tenant is the most basic unit of categorization for topics (more fundamental than the namespace and topic name).
To each tenant in a Pulsar instance you can assign:
Tenants and namespaces are two key concepts of Pulsar to support multi-tenancy.
pulsar-admin
CLI tool. For instance, a tenant with different applications can create a separate namespace for each application.Names for topics in the same namespace will look like this:
persistent://tenant/app1/topic-1 persistent://tenant/app1/topic-2 persistent://tenant/app1/topic-3
Pulsar is a multi-tenant event streaming system. Administrators can manage the tenants and namespaces by setting policies at different levels. However, the policies, such as retention policy and storage quota policy, are only available at a namespace level. In many use cases, users need to set a policy at the topic level. The namespace change events approach is proposed for supporting topic-level policies in an efficient way. In this approach, Pulsar is used as an event log to store namespace change events (such as topic policy changes). This approach has a few benefits:
Each namespace has a system topic named __change_events
. This system topic stores change events for a given namespace. The following figure illustrates how to leverage it to update topic-level policies.
__change_events
) of the namespace.__change_events
) to receive the change events of the namespace.