Chris Bartholomew

At Kesque, it’s our mission to empower developers to build cloud-native distributed applications by making cloud-agnostic, high-performance messaging technology easily available to everyone. Developers want to write distributed applications or microservice but don’t want the hassle of managing complex message infrastructure or getting locked into a particular cloud vendor. They need a solution that just works. Everywhere.

When you set out to build the best messaging infrastructure service, the first step is to pick the right underlying messaging technology. There are lots of choices out there, from various open-source projects like RabbitMQ, ActiveMQ, and NATS to proprietary solutions such as IBM MQ or Red Hat AMQ. And, of course, there is Apache Kafka, which is almost synonymous with streaming. But we didn’t go with Apache Kafka, we went with Apache Pulsar.

So why did we build our messaging service using <a href="https://kesque.com/what-is-apache-pulsar/">Apache Pulsar</a>?&nbsp; Here are the top seven reasons why we chose Apache Pulsar over Apache Kafka.

<h2>1. Streaming and queuing come together</h2>

Apache Pulsar is like two products in one. Not only can it handle high-rate, real-time use cases like Kafka, but it also <a href="https://pulsar.apache.org/docs/en/concepts-messaging/#subscription-modes">supports standard message queuing</a> patterns, such as competing consumers, fail-over subscriptions, and easy message fan out. Apache Pulsar automatically keeps track of the client read position in the topic and stores that information in its high-performance distributed ledger, Apache BookKeeper.

Unlike Kafka, Apache Pulsar can handle many of the use cases of a traditional queuing system, like RabbitMQ. So instead of running two systems — one for real-time streaming and one for queuing — you do both with Pulsar. It’s a two-for-one deal, and those are always good.

<h2>2. Partitions, but not necessarily partitions</h2>

If you use Kafka, you know about partitions. All topics are partitioned in Kafka. Partitioning is important because it increases throughput. By spreading the work across partitions and therefore multiple brokers, the rate that can be processed by a single topic goes up. But what if you have some topics that don’t need high rates. In these simple cases, wouldn’t it be nice to not have to worry about partitions and the API and management complexity that comes along with them?

Well, with Apache Pulsar it can be that simple. If you just need a topic, then use a <a href="https://pulsar.apache.org/docs/en/concepts-messaging/#topics">topic</a>. You don’t have to specify the number of partitions or think about how many consumers the topic might have. Pulsar <a href="https://pulsar.apache.org/docs/en/concepts-messaging/#subscription-modes">subscriptions</a> allow you to add as many consumers as you want on a topic with Pulsar keeping track of it all. If your consuming application can’t keep up, you just use a shared subscription to distribute the load between multiple consumers.

And if you really do need the performance of a partitioned topic, you can do that, too. Pulsar has <a href="https://pulsar.apache.org/docs/en/concepts-messaging/#partitioned-topics">partitioned topics</a> if you need them — but only if you need them.

<h2>3. Logs are good, distributed ledgers are better</h2>

The Kafka team deserves credit for the <a href="https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying">insight</a> that a log is a great abstraction for a real-time data exchange system. Because logs are append-only, data can be written to them quickly, and because the data in a log is sequential, it can be extracted quickly in the order that it was written. Sequential reading and writing is fast, random is not. Persistent storage interactions are a bottleneck in any system that offers data guarantees, and the log abstraction makes this about as efficient as possible.

Simple logs are great. But they can get you into trouble when they get large. Fitting a log on a single server becomes a challenge. What happens if it gets full and you need to scale out? And what happens if the server storing the log fails and needs to be recreated from a replica?&nbsp;

Copying a large log from one server to another, while efficient, can still take a long time. If your system is trying to do this while keeping up with real-time data, this can be quite a challenge. Check out “Adding a New Broker Results in Terrible Performance” in the blog post <a href="https://www.confluent.io/blog/stories-front-lessons-learned-supporting-apache-kafka/">Stories from the Front: Lessons Learned from Supporting Apache Kafka</a> for some color on this.

Apache Pulsar avoids the problem of copying large logs by breaking the log into segments. It distributes those segments across multiple servers while the data is being written by using Apache BookKeeper as its <a href="https://pulsar.apache.org/docs/en/concepts-architecture-overview/#apache-bookkeeper">storage layer</a>. This means that the log is never stored on a single server, so a single server is never a bottleneck. Failure scenarios are easier to deal with and scaling out is a snap. Just add another server. No rebalancing needed.

<h2>4. Stateless brokers, what?</h2>

Stateless is music to the ears of anyone building cloud-native applications. Stateless components start up quickly, are interchangeable, and scale seamlessly. Wouldn’t it be great if a message broker was stateless?

The Kafka broker is not stateless. Each broker contains the complete log for each of its partitions. If one broker fails, not just any broker can take over for it. If the load is getting too high, you can’t simply add another broker. Brokers must synchronize state from other brokers that contain replicas of its partitions.

In the Apache Pulsar architecture, the <a href="https://pulsar.apache.org/docs/en/concepts-architecture-overview/#brokers">brokers are stateless</a>. Yes, you heard that right. A completely stateless system wouldn’t be able to persist messages, so Apache Pulsar does maintain state, just not in the brokers. In Pulsar architecture, the brokering of data is separated from the storing of data. The brokers accept data from producers and send data to consumers, but the data is stored in Apache BookKeeper.

Because Pulsar brokers are stateless, if the load gets high, you just need to add another broker. The broker starts up quickly and gets to work right away.

<h2>5. Geo-replication for dummies</h2>

Geo-replication is a first-class feature in Pulsar. It’s not a bolt-on or a proprietary add-on. Pulsar was <a href="https://pulsar.apache.org/docs/en/administration-geo/">designed with geo-replication</a> in mind. Configuring it is easy and it just works. So whether it’s a globally distributed application or disaster recovery scenario, you can set it up with Pulsar. No Ph.D. needed.

<h2>6. Consistently faster</h2>

<a href="http://openmessaging.cloud/docs/benchmarks/pulsar/">Benchmark tests</a> have shown that Pulsar delivers higher throughput along with lower and more consistent latency. Faster and more consistent is better. What else is there to say?

<h2>7. It’s all Apache open source</h2>

Pulsar has many of the same features as Kafka — such as geo-replication, in-stream message processing (Pulsar Functions), input and output connectors (Pulsar IO), SQL-based topic queries (Pulsar SQL), schema registry, as well as features Kafka doesn’t have like tiered storage and multi-tenancy.&nbsp;

All these features are part of the <a href="https://pulsar.apache.org/en/">Apache open source project</a>.

Pulsar is not a collection of open-source and closed-source features or open-source features controlled by a commercial entity. All its many useful features are open-source under the Apache umbrella. And unless the unthinkable happens, all this goodness will stay open source.

<h2>Conclusion</h2>

As you can see, we had lots of reasons to pick Apache Pulsar for building our messaging infrastructure service. And we didn’t even go into the reasons it’s easier to build a service around Pulsar, such as multi-tenancy, namespaces, authentication and authorization, documentation, Kubernetes friendliness.

If you’re looking to build out a messaging infrastructure service, give Pulsar a try. You won’t regret it.

Want to try out Apache Pulsar?&nbsp;<a href="https://astra.datastax.com/register">Sign up now</a>&nbsp;for&nbsp;<a href="https://www.datastax.com/products/astra-streaming">Astra Streaming</a>, our fully managed Apache Pulsar service. We’ll give you access to its full capabilities entirely free through beta. See for yourself how easy it is to build modern data applications and let us know what you’d like to see to make your experience even better.&nbsp;

(Editor's note: <a href="https://www.datastax.com/press-release/datastax-delivers-scale-out-enterprise-event-streaming-modern-data-apps">DataStax acquired Kesque in January 2021</a>.)

7 Reasons We Chose Apache Pulsar over Apache Kafka

Chris Bartholomew

Share

Share

1. Streaming and queuing come together

2. Partitions, but not necessarily partitions

3. Logs are good, distributed ledgers are better

4. Stateless brokers, what?

5. Geo-replication for dummies

6. Consistently faster

7. It’s all Apache open source

Conclusion

More Company

DataStax Acquires Langflow to Accelerate Generative AI Development

The Top 5 DataStax Stories from 2023

2023 Recap: Data = AI

DataStax Astra DB Nabs Three Prestigious 2023 TrustRadius “Best of” Awards, Dominates the Vector Databases Category

One-stop Data API for Production GenAI