Describe Pulsar's native multi-tenancy and geo-replication model, and contrast it with how Kafka achieves the same goals.

**Multi-tenancy.** *Pulsar* has a built-in three-level naming hierarchy. A fully-qualified topic looks like `persistent://<tenant>/<namespace>/<topic>`: - **Tenant** — top-level isolation unit, typically a team, business unit, or customer. Has its own admin roles and an *allowed clusters* list. - **Namespace** — the policy/administrative grouping within a tenant. *This is where most knobs live:* retention policy, backlog quota, message TTL, deduplication, schema-compatibility rules, authorization (which roles can produce/consume), throttling, and the set of clusters for geo-replication. - **Topic** — the actual stream/queue, persistent or non-persistent. Because quotas, auth, and isolation are first-class at tenant/namespace level, a single Pulsar cluster can safely host many teams/customers — that's what 'native multi-tenancy' means. Pulsar can also pin tenants/namespaces to specific brokers (*broker isolation policies*) so a noisy tenant doesn't starve others. *Kafka* has a **flat** topic namespace — just topic names, no tenant/namespace objects. Multi-tenancy is *convention + add-ons*: prefix topics by team (`teamA.orders`), apply per-principal **ACLs**, set **client quotas** (byte-rate/request-rate per user/client-id), and possibly run separate clusters per tenant for hard isolation. It works, but tenancy is assembled by the operator rather than provided by the platform. **Geo-replication.** *Pulsar* treats replication as a *namespace property*. You define multiple named clusters (each its own brokers + BookKeeper, sharing a global metadata view via *configuration store*). Setting a namespace's replication clusters to, say, `[us-east, eu-west]` makes brokers asynchronously forward locally-published messages to the other regions' brokers. Key mechanics: - It is **async** by default (low local latency; cross-region lag). - Each message carries its **origin cluster**, so replication doesn't loop in active-active topologies — a message originating in eu-west isn't bounced back to eu-west. - Subscriptions can optionally be replicated too (replicated subscriptions) so consumers can fail over regions with cursor continuity. - It supports active-active (every region produces and consumes) without external processes. *Kafka* has no built-in cross-cluster replication. You use: - **MirrorMaker 2 (MM2)** — built on Kafka Connect; it copies topics, consumer-group offsets, and ACLs between clusters, renaming topics with a cluster prefix (e.g. `us-east.orders`) to prevent loops. It's a separate deployment to run, monitor, and tune. - **Cluster Linking** (Confluent, commercial) — byte-for-byte mirroring keeping the same topic name, more seamless but proprietary. The philosophical difference: in Pulsar a topic in a replicated namespace is *one logical topic that exists in several regions*; in Kafka (MM2) you have *distinct topics per cluster* tied together by a copying process and naming convention. **Edge cases / gotchas.** - Pulsar geo-replication is async, so a region failover can lose the not-yet-replicated tail — RPO is non-zero, same as MM2. - Active-active with the same key produced in two regions can still create conflicting orderings; Pulsar's loop-prevention handles duplication, not application-level conflict resolution. - Multi-tenancy isolation in Pulsar is logical by default; a truly hostile/noisy tenant may still need broker isolation policies or separate bookie pools for hardware-level isolation, analogous to Kafka's 'just run a separate cluster' answer.