Why Pulsar?

Apache Pulsar was designed with a multi-layer architecture in which each layer is scalable, distributed, and decoupled from the other layers. With Pulsar, you can add new topics as needed and seamlessly scale performance. Scaling in Pulsar is a simple, non-disruptive operation.

With partition-centric storage architectures, expanding capacity often requires partition rebalancing, which in turn requires recopying entire partitions to new nodes. Recopying data is expensive and prone to errors, and it consumes network bandwidth and I/O. With Pulsar, you can scale as needed without the expense and disruption of repartitioning. Pulsar’s decoupling of the processing, message serving and storage layers means you can independently scale resources.

Apache Pulsar replicates each message to multiple storage nodes and was designed to be able to handle both single and multiple node failures. With stateless brokers, Pulsar only needs to update metadata to transfer ownership from one broker to another when a topic is moved to a different broker and no data is copied during this transfer of ownership.

Pulsar supports full-mesh replication, in which individual topics can be replicated to any number of external data centers and replication is done in multiple directions, all with a simple configuration setting at the tenant level. In Pulsar, all replica repairs happen in the background and are handled by the storage layer to avoid impacting other workloads being processed by brokers.