Alchemy Micro-Service Framework: Using RabbitMQ Instead of HTTP

Re:Alchemy Micro-Service Framework: Using RabbitMQ Instead o... by abrookewood on Tuesday March 15, 2016 @12:45AM (#11287503)

I spoke to Kyle Kingsbury (Aphyr) about 9 months ago and at that time, the only queue or pub/sub system he thought was relatively safe from partition errors was Kafka. Not sure if his position has changed recently.

[ Parent | on HN ]

Re:Alchemy Micro-Service Framework: Using RabbitMQ Instead o... by lobster_johnson on Tuesday March 15, 2016 @11:29AM (#11290352)

Indeed, though this is irrelevant to this particular use case.

NATS doesn't have replication, sharding or total ordering. Consistency is a challenge for clustered messaging brokers that need this.

With NATS, queues are effectively sharded by node. If a node dies, its messages are lost. Incoming messages to the live nodes will still go to connected subscribers, and subscribers are expected to reconnect to the pool of available nodes. Once a previously dead node rejoins, it will start receiving messages.

NATS in this case replaces something like HAProxy; a simple in-memory router of requests to backends.

[ Parent | on HN ]

Re:Alchemy Micro-Service Framework: Using RabbitMQ Instead o... by abrookewood on Tuesday March 15, 2016 @08:14PM (#11294056)

Ahh .. OK, that makes it clearer. Thanks.

[ Parent | on HN ]

Re:Alchemy Micro-Service Framework: Using RabbitMQ Instead o... by StreamBright on Tuesday March 15, 2016 @03:46AM (#11288109)

This is also my personal experience with message queues, even though I haven't had a chance to work with NATS yet. Kafka is just a really solid piece of engineering when you need 5-50 servers. With that many servers you can handle millions of messages per second that usually enough for a mid size company. I am not sure about higher scale but I believe LinkedIN has much larger clusters.

[ Parent | on HN ]