Earlier quoted context omitted.
> Thats kind of like saying dont use any software libraries because they all use the standard lib indirectly so you may as well just use that? This is decent advice, IMO. The cost of dependency management is often vastly understated.
That’s Not Invented Here syndrome, and it’s decidedly bad advice. The cost of dependency management may be understated but it’s always less than the cost of reimplementing everything found in established libraries.
RabbitMQ vs. Kafka – An Architect’s Dilemma (Part 1)
171–173 of 173 posts
Re: RabbitMQ vs. Kafka – An Architect’s Dilemma (Part 1)
#172> one is a message broker, and the other is a distributed streaming platform I think this is an odd way of putting it. One is smart messaging; dumb clients. The other is dumb messaging; smart clients. It turns out the latter (i.e. Kafka) scales wonderfully so you can send more data, but you add complexity to your clients, who can't just now pluck messages off a queue to process, or have messages retry upon the first…
Re: RabbitMQ vs. Kafka – An Architect’s Dilemma (Part 1)
#173Earlier quoted context omitted.
Rabbitmq is FOSS, has lots of language bindings. It has persistence, durability, and doesn't require a separate orchestrator.
I was mostly comparing against Kafka but yes I should def take a look at RabbitMQ again. I remember there was some reason it wasn’t a good fit for me but can’t recall what it was. Are the horizontal scaling issues solved now?