Apache Kafka is an open-source stream processing platform developed by the Apache Software Foundation written in Scala and Java. The Kafka event streaming platform is used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.
N/A
RabbitMQ
Score 7.8 out of 10
N/A
RabbitMQ, an open source message broker, is part of Pivotal Software, a VMware company acquired in 2019, and supports message queue, multiple messaging protocols, and more.
RabbitMQ is available open source, however VMware also offers a range of commercial services for RabbitMQ; these are available as part of the Pivotal App Suite.
Apache Kafka is built for scale. From high throughput and real-time data streaming, it has a strong advantage over RabbitMQ with its low latency. This put Apache Kafka at the forefront as the platform of choice for large datasets messaging and ensuring scalability when data …
Apache Kafka can work at a higher scale as compared to SQS. It can work with higher size per message and millions of messages per second. Moreover it can be scaled horizontally by adding more brokers to the cluster. SQS is good enough for simple use cases like making a task …
I used other messaging/queue solutions that are a lot more basic than Confluent Kafka, as well as another solution that is no longer in the market called Xively, which was bought and "buried" by Google. In comparison, these solutions offer way fewer functionalities and respond …
Apache Kafka is open-sourced, scales great has cloud agnostics and performs better than Amazon Kinesis [in my view]. Amazon Kinesis has some limitations and vendor lockin is not something I [like]. With Confluent operators you can easily install it on a kubernetes cluster.
We really needed to get away from using a SQL database to act as a queue for processing records, so a new solution was needed. Kafka is a leading software application initially designed for queuing messages which is essentially what we were looking for. It has a great user …
For us, Kafka really doesn't have a 1:1 alternative. We have used ActiveMQ extensively and we still use it as a lighter option for small messages. The situation is similar with Redis - although it could be used like a Kafka alternative, we do use it just as a per-component …
Apache Kafka is much more scalable and more reliable. Does not depend on memory, works well on rotational disks and that makes it a cheaper to use solution on low hardware requirements. Running multiple consumers on the same topic can also mean processing the same data again …
All stack tech helps our app and system. These technologies allow us to have the data available faster between different regions (due to our particular configuration) and thus the data and processing load of each system is lower. This allows the systems to be used more …
Kafka is not a real messaging broker implementation as RabbitMQ or TIBCO EMS/JMS are. Although it can be used as messaging, we like the idea behind the Kafka (data isn't "passing by," instead it remains centra, so the client can revisit the data if necessary). This also …
Confluent Cloud is still based on Apache Kafka but it has a subscription fee so, from a long term perspective, it is wiser to deploy your own Kafka instance that spans public and private cloud. Amazon Kinesis, Google Cloud Pub/Sub do not do well for a very number of messages …
I would only use RabbitMQ over Kafka when you need to have delay queues or tons of small topics/queues around. I don't know too much about Pulsar - currently evaluating it - but it's supposed to have the same or better throughput while allowing for tons of queues. Stay tuned - I …
Kafka is faster and more scalable, also "free" as opensource (albeit we deploy using a commercial distribution). Infrastructure tends to be cheaper. On the other hand, projects must adapt to Kafka APIs that sometimes change and BAU increases until a major 1.x version comes out …
RabbitMQ has a few advantages over Azure Service Bus 1) RMQ handles substantially larger files - ASB tops out at 100MB, we use RabbitMQfor files over 200MB 2) RabbitMQ can be easily setup on prem - Azure Service Bus is cloud only
It is very easy to use as it has a simple function to connect and use RabbitMQ. It is having Fast Learning curve, Any newbies can learn it in a week or month. It is having proper documentation, we are able to find all the details about its functionality and usage of it. The …
I have not used other products other than a roll-your-own solution. The Selection of RabbitMQ was made before I began working on the project but I was able to leverage it well without making major changes to the existing apps. This was particularly helpful in lowering risks. I …
For basic use cases, SQS is way easy to deploy and maintain compared to RabbitMQ. RabbitMQ can cover a lot more use-cases but actually, we did not face specific scenarios that make it necessary to come back to RabbitMQ.
It is just better documented and seems a better fit given that is done using erlang. PubSub+ low level approach seems unsafe. They work with custom hardware whereas Pivotal RabbitMQ seem a better fit for generic hardware (cloud).
Honestly, though we're still trying out Kafka and Pulsar, I'd go with them for message broker and as traffic buffers. We are only still using RabbitMQ because it's hard to transition off after writing tons of code custom-built for RabbitMQ. Kafka is better because it's way more …
None of the options in the list are really similar products. We use Apache Camel in conjunction with RabbitMQ and we also use Oracle Integration Cloud and WSO2 for messaging. Integration Cloud is SaaS-based and low code, so it's drastically different in that regard. WS02 is …
Apache Kafka and RabbitMQ are both message queue software designed to enable applications to communicate with each other asynchronously. Though Apache Kafka works as a streaming platform that performs messaging tasks, both it and RabbitMQ function as traditional message queue software.
Both RabbitMQ and Apache Kafka are more popular with mid-sized to large organizations. Larger enterprises use Apache Kafka is slightly more often, while mid-sized businesses prefer RabbitMQ.
Features
Though Apache Kafka and RabbitMQ are both robust message queue tools, they each offer a few standout features that set them apart from one another.
Apache Kafka performs well with large amounts of data, transferring messages quickly, even in high volumes. This high performance makes Apache Kafka a good choice for organizations with many messages in the queue, perhaps due to batch consumers that may not be connected to the message queue at all times. Apache Kafka is also very scalable, increasing performance for extreme workloads can be as simple as running it on additional nodes.
RabbitMQ offers many client libraries for languages like Python, PHP, JavaScript, and more. This multitude of client libraries makes it easy for most businesses to start using RabbitMQ without compatibility issues. RabbitMQ supports complex routing, which can be important messages that need to be delivered to consumers in less straightforward ways. RabbitMQ also provides a built-in user interface out of the box that is easy for users to manage, making RabbitMQ a relatively user-friendly message queue software.
Limitations
Despite their essential message queue features, Apache Kafka and RabbitMQ both have a few limitations that are worth considering.
Apache Kafka lacks the variety of client libraries that RabbitMQ supports. Though first and third-party developers are building more client libraries, most are not available at present. Similarly, there are third-party tools that add monitoring features to Apache Kafka, but they are not available out of the box, which can make it more difficult to use. Implementation for Apache Kafka can also be challenging and time-consuming, particularly for an organization that hasn’t purchased any vendor support.
RabbitMQ experiences slower performance as applications append more messages to the queue. For organizations with large amounts of data in their message queue, RabbitMQ can’t match Apache Kafka’s speed. Users may also have a difficult time accessing information within the message queue without pulling messages out of the queue.
Pricing
RabbitMQ and Kafka are both open-source software, meaning their source code is available online for free. Many vendors offer support for both software options, ranging from implementation to ongoing maintenance. Pricing for support is quoted based on the features the vendor offers as well as the needs of the organization.
For brokering messages, Confluent Kafka is well suited since it offers a managed solution ready to use. Scenarios where the solution is not very well suited are for example, where pricing is an issue. The solution costs quite a lot for basic usage (for example: for 3 clusters, pricing is above 100k$ a year).
If you are looking for a message broker, RabbitMQ is pretty good. Its API lets you create tons of queues on demand and publish to all of them at once, while you can have 10+ consumers on each queue. It also does a good job of absorbing bursts of traffic. We've seen our queues get backed up to 3 million messages with no problem. In the modern era of GDPR, you may run into problems with keeping messages encrypted out of the box in-flight and at-rest with RabbitMQ. Not saying it's impossible, but it's tough to set up and you have to pay a high overload.
Apache Kafka is able to handle a large number of I/Os (writes) using 3-4 cheap servers.
It scales very well over large workloads and can handle extreme-scale deployments (eg. Linkedin with 300 billion user events each day).
The same Kafka setup can be used as a messaging bus, storage system or a log aggregator making it easy to maintain as one system feeding multiple applications.
What RabbitMQ does well is what it's advertised to do. It is good at providing lots of high volume, high availability queue. We've seen it handle upwards of 10 million messages in its queues, spread out over 200 queues before its publish/consume rates dipped. So yeah, it can definitely handle a lot of messages and a lot of queues. Depending on the size of the machine RabbitMQ is running on, I'm sure it can handle more.
Decent number of plugins! Want a plugin that gives you an interface to view all the queues and see their publish/consume rates? Yes, there's one for that. Want a plugin to "shovel" messages from one queue to another in an emergency? Check. Want a plugin that does extra logging for all the messages received? Got you covered!
Lots of configuration possibilities. We've tuned over 100 settings over the past year to get the performance and reliability just right. This could be a downside though--it's pretty confusing and some settings were hard to understand.
The Kafka Tool is a community-made Java application that looks and feels from the past century.
Logging can be confusing. This certainly shows when we have to do troubleshooting.
Hybrid scenarios - pub/sub, but there are services in and outside a Kubernetes cluster. Then there are a ~3 options, but only 2 (the harder ones) are production-safe.
It breaks communication if we don't acknowledge early. In some cases our work items are time consuming that will take a time and in that scenario we are getting errors that RabbitMQ broke the channel. It will be good if RabbitMQ provides two acknowledgements, one is for that it has been received at client side and second ack is client is completed the processing part.
Kafka has suited our use case very well so far. Going forward we are planning to expand our platform manifold so the load on Kafka and our reliance on Kafka is going to increase only.
Apache Kafka is highly recommended to develop loosely coupled, real-time processing applications. Also, Apache Kafka provides property based configuration. Producer, Consumer and broker contain their own separate property file
RabbitMQ is very usable if you are a programmer or DevOps engineer. You can setup and configure a messaging system without any programmatic knowledge either through an admin console plugin or through a command-line interface. It's very easy to spin up additional consumers when volume is heavy and it's very easy to manage those consumers either through automated scripting or through their admin console. Because it's language agnostic it integrates with any system supporting AMQP.
Support for Apache Kafka (if willing to pay) is available from Confluent that includes the same time that created Kafka at Linkedin so they know this software in and out. Moreover, Apache Kafka is well known and best practices documents and deployment scenarios are easily available for download. For example, from eBay, Linkedin, Uber, and NYTimes.
I gave it a 10 but we do not have a support contract with any company for RabbitMQ so there is no official support in that regard. However, there is a community and questions asked on StackOverflow or any other major question and answer site will usually get a response.
Apache Kafka is built for scale. From high throughput and real-time data streaming, it has a strong advantage over RabbitMQ with its low latency. This put Apache Kafka at the forefront as the platform of choice for large datasets messaging and ensuring scalability when data scale up tremendously. RabbitMQ however has its strengths in traditional messaging. Routing and message delivery reliability are the bedrock of RabbitMQ and this is where RabbitMQ excels. In my previous workplace, RabbitMQ was of choice as reliability matters more than scale. In two words. Apache Kafka for scale, RabbitMQ for reliability. And for cloud deployment and large dataset messaging in what I am doing now, Apache Kafka is the default choice.
It is very easy to use as it has a simple function to connect and use RabbitMQ. It is having Fast Learning curve, Any newbies can learn it in a week or month. It is having proper documentation, we are able to find all the details about its functionality and usage of it. The Features of RabbitMQ are providing are matching with our business requirements.
Positive: bursts of traffic on special holidays are easy to handle because Kafka can absorb and buffer all the messages we need to process long enough to let an understaffed set of back-end services catch up on processing. Hard to put a number to it but we probably save $5k a month having fewer machines running.
Positive: makes decoupling the web and API services from the deeper back-end services easier by providing topics as an interface. This allowed us to split up our teams and have them develop independently of each other, speeding up software development.
Negative: our engineers have made mistakes such as accidentally dropping a few thousand messages due to the CLI being confusing to use, and as a result a customer lost some of their precious data. I'd say that was more our fault than Kafka's though.
Earlier we had a problem with missing work items with our own implementation but later using RabbitMQ is solved a problem. Now our job processing mechanism is highly reliable.
We also had a problem with scaling, processing 1k work items per second. RabbitMQ helped us to scale well with increasing work items.