4 ms·

> In a message queuing system, there is no rebalancing - you just add nodes, which then also get messages, typically in a round-robin fashion. And hope that th

> In a message queuing system, there is no rebalancing - you just add nodes, which then also get messages, typically in a round-robin fashion. And hope that the DNS\config propagates to the calling client and that the library can reliably add and remove nodes. > Retrying Wanna bet it's a built in feature in your messaging system? Cause the whole publish op can fail at which point you have to retry sending it. or it published but you lost the ack (seen with AQ more than once) so now you send that message again and hope you remembered that whole duplicate message handling

stolsvik 4y ago
> And hope that the DNS\config propagates to the calling client and that the library can reliably add and remove nodes. This is not how it works. A messaging broker client connects to the message broker. The client then creates receivers for one or multiple queues. If the broker has multiple clients receiving from the same queue, it uses a round-robin dispatch to the clients. I fail to see how DNS or config, or "reliably add and remove" factors in here? > Wanna bet it's a built in feature in your messaging system? Yes? This is not using pub/sub, but queuing. (There is an option of using publish/subscribe, but that is only meant for special cases like updating a GUI, or "broadcasting" an event like "invalidate cache for user X") Message Queuing can be transactional. Mats leverages this. I have written about it multiple places both on this HN discussion, and on the webpage.