Apache Kafka

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.

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 queue which other components rarely access. Kafka is just easier for our group of developers to use and encompass more use cases without having to introduce more tools into the mix.

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 community and is used across the industry. We also use and trust several other products from Confluent which helped seal the decision.

Kafka is simple and lower in price.

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 and again and this can be a big plus.

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 efficiently for other purposes.

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 relieves the pressure of keeping the old duplicated data copy on both the publisher and the consumer sides.

We had lots of problems with active mq. That is why we started using Apache Kafka.

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 and doesn't provide ordering guarantees as Apache Kafka or Confluent. Apache Kafka does better in scaling and availability than IBM MQ and Rabbit MQ.

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 might update this review after we finish evaluating Pulsar. It's much less battle-tested though.

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 and adds stability to the product.