AMQP is a great way to send messages over-the-wire. However, there are some cases where we might prefer to use a natively distributed message queue. We would like to keep current infrastructure to send server-to-server messages with AMQP, and use NSQ sometimes to broadcast a message to all servers. It can be done with AMQP sofwares as RabbitMQ (pub/sub approach), but as I said, it's not native and requires overcoming limitations. There is already a stable, working client library for golang ( https://github.com/nsqio/go-nsq ).
Nsq is not good to handle slow consumer. One message will requeue if consumer last 15 minutes.
So it may be not a good idea to use nsq in machinery.
See Related issue
AMQP is a great way to send messages over-the-wire. However, there are some cases where we might prefer to use a natively distributed message queue. We would like to keep current infrastructure to send server-to-server messages with AMQP, and use NSQ sometimes to broadcast a message to all servers. It can be done with AMQP sofwares as RabbitMQ (pub/sub approach), but as I said, it's not native and requires overcoming limitations. There is already a stable, working client library for golang ( https://github.com/nsqio/go-nsq ).