Apache Pulsar

Use it when

• Many teams share one streaming platform: multi-tenancy, quotas, and namespaces are architectural features, not conventions layered on top.
• You need built-in geo-replication; asynchronous multi-cluster replication with replicated subscriptions ships in the box.
• Your consumers mix patterns: log-style replay and shared work queues coexist through subscription modes on the same topic.
• Adding capacity must not mean rebalancing data; stateless brokers over BookKeeper segments make scaling a serving change, not a data move.

Think twice when

• A small team runs it: brokers plus BookKeeper plus a metadata store is one of the largest footprints in this capability, against Kafka in KRaft mode or Redpanda's single binary.
• The Kafka ecosystem is the requirement; protocol handlers exist, but tooling and hiring gravitate to Kafka itself.
• Your volume is modest; the architecture earns its keep at scale it may never see.

How it runs

Self-hosted as brokers, a BookKeeper ensemble, and a metadata store (Oxia recommended for new deployments, ZooKeeper still supported), commonly on Kubernetes. Pulsar IO connectors and Pulsar Functions run on worker nodes; tiered offload moves old segments to object storage. Managed offerings come from StreamNative and others.