Live data from Hacker News

RabbitMQ 4.0

github.com

71–80 of 120 posts

Re: RabbitMQ 4.0

#71
post #3

I've regarded RabbitMQ as a secret weapon in plain sight for years. The killer reason people don't use it more is it "doesn't scale" to truly enormous sizes, but for anyone with less than a million users it's great. Too many people end up with their own half rolled pubsub via things like grpc, and they'd be far better off using this, particularly in the early stages of development.

I've seen it used for a company with way, way in excess of a million users. We used it for a system with 100M+ users for our login systems and in general all of our main account systems relied on it. Most of the brokers were always running at 15k to 25k messages per second.

I loved it and the only issues we had were due to our fuckups.

Re: RabbitMQ 4.0

#72
post #3

I've regarded RabbitMQ as a secret weapon in plain sight for years. The killer reason people don't use it more is it "doesn't scale" to truly enormous sizes, but for anyone with less than a million users it's great. Too many people end up with their own half rolled pubsub via things like grpc, and they'd be far better off using this, particularly in the early stages of development.

For me the killer feature of Kafka is that topics are persistent until the data expires. Meaning different readers can be working at different offsets. And you can rewind or fast forward the offset you are reading, which can really be a life saver when things go sideways.

Does RabbitMQ have equivalent features?

Re: RabbitMQ 4.0

#73
post #68

Earlier quoted context omitted.

When you said that number, I had a completely different reaction. 20 messages per second is absolutely nothing, $0.50 per day for that is dreadful. A $5 per month ($0.16 per day) VPS can deliver many thousands of messages per second.

When I read this message I think this an absolutely terrible waste of time for a startup/small company. I want to spend my time building features not infrastructure.

This stuff is so trivially easy these days. 20 years ago it was hard to deploy a clustered message queue application, but now we've got so much open source tooling. Are you telling me you can't deploy RabbitMQ in an afternoon? Give it a day or two and you've got a monitoring stack and some swanky GitOps. Now your OpEx has been reduced 80x for hardly doing anything. As for continual maintenance, us-east-1 has gone down more times in the past year than my RabbitMQ cluster has gone down in 5. Because the tech really has improved, and it really is easy now.

Re: RabbitMQ 4.0

#74
post #70
post #69

Earlier quoted context omitted.

I think it is fairly clear. If you are building a product of passion that you may tinker with for years, by all means cut costs as much as possible. If you are an actual early stage venture I don't believe those costs meet a high enough threshold to matter.

It depends, as things usually do. $20 here, $10 there, eventually ends up as $600 monthly or more, and no customer anywhere in sight. That may, or may not be sustainable or make sense. Flush with cash? Knock yourself out. Bootstrapping? You can spend that money a lot more effectively than just loading up on a bunch of overpriced SaaS products to make life easier. You have to earn the easy route by growing your revenu…

It does not depend though. It’s pretty clear that it’s how you value your time which is what I was getting to.

Re: RabbitMQ 4.0

#75
post #7

Earlier quoted context omitted.

So how about NATS compared to RabbitMQ? If building from scratch, what would drive a design or team towards NATS?

Two different models. The metaphor I like to use is that RabbitMQ is a postal system, while NATS is a switchboard. RabbitMQ is a "classical" message broker. It routes messages between queues. Messages are treated like little letters that fly everywhere. They're filed in different places, and consumers come by and pick them up. Core NATS isn't really a message broker, but more of a network transport. There are no queu…

Sorry, I'm not familiar with this tech so looked up Jetstream and it seems to be archived https://github.com/nats-io/jetstream. Not sure that would be a good endorsement to try to use something that is no longer maintained or am I looking at the wrong one?

Re: RabbitMQ 4.0

#76
post #3

I've regarded RabbitMQ as a secret weapon in plain sight for years. The killer reason people don't use it more is it "doesn't scale" to truly enormous sizes, but for anyone with less than a million users it's great. Too many people end up with their own half rolled pubsub via things like grpc, and they'd be far better off using this, particularly in the early stages of development.

This is how I feel about NATS: https://nats.io/ It's an infinitely more friendly version of Kafka, pub/sub, etc that is extremely lightweight. Yet every environment trends towards Kafka because it was "chosen" by the big corps.

I agree. NATS is much more simplistic to use and deploy. Easy to run locally for development. Jetstream offers useful features like persistent streams, and kv and object stores.

Re: RabbitMQ 4.0

#78
post #3

I've regarded RabbitMQ as a secret weapon in plain sight for years. The killer reason people don't use it more is it "doesn't scale" to truly enormous sizes, but for anyone with less than a million users it's great. Too many people end up with their own half rolled pubsub via things like grpc, and they'd be far better off using this, particularly in the early stages of development.

This is how I feel about NATS: https://nats.io/ It's an infinitely more friendly version of Kafka, pub/sub, etc that is extremely lightweight. Yet every environment trends towards Kafka because it was "chosen" by the big corps.

https://nsq.io/ is also very reliable, stable, lightweight, and easy to use.

Re: RabbitMQ 4.0

#79

Earlier quoted context omitted.

Two different models. The metaphor I like to use is that RabbitMQ is a postal system, while NATS is a switchboard. RabbitMQ is a "classical" message broker. It routes messages between queues. Messages are treated like little letters that fly everywhere. They're filed in different places, and consumers come by and pick them up. Core NATS isn't really a message broker, but more of a network transport. There are no queu…

Sorry, I'm not familiar with this tech so looked up Jetstream and it seems to be archived https://github.com/nats-io/jetstream . Not sure that would be a good endorsement to try to use something that is no longer maintained or am I looking at the wrong one?

> JetStream went Generally Available in NATS 2.2.0 the documentation is now in the core NATS documentation.

https://docs.nats.io/jetstream

Re: RabbitMQ 4.0

#80
post #3

I've regarded RabbitMQ as a secret weapon in plain sight for years. The killer reason people don't use it more is it "doesn't scale" to truly enormous sizes, but for anyone with less than a million users it's great. Too many people end up with their own half rolled pubsub via things like grpc, and they'd be far better off using this, particularly in the early stages of development.

This is how I feel about NATS: https://nats.io/ It's an infinitely more friendly version of Kafka, pub/sub, etc that is extremely lightweight. Yet every environment trends towards Kafka because it was "chosen" by the big corps.

nats looks more like a more friendly version of rabbitmq or zeromq than of kafka from these docs: https://docs.nats.io/reference/reference-protocols/nats-prot...
Post reply on HN