Live data from Hacker News

RabbitMQ vs. Kafka – An Architect’s Dilemma (Part 1)

eranstiller.com

171–173 of 173 posts

Re: RabbitMQ vs. Kafka – An Architect’s Dilemma (Part 1)

#171
post #123

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.

Who has the time to count the cost. Just keep shipping and worry about the costs later is the reality in a large portion of the tech ecosystem.

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…

Every decision has a consequence. There are a lot more options depending on the use case.

Re: RabbitMQ vs. Kafka – An Architect’s Dilemma (Part 1)

#173
post #155

Earlier 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?

Yes, if you use quorum queues
Post reply on HN