disclaimer: co-author of NSQ [1] here Agreed. Message queues play an important role for us (bitly) in being a layer of fault tolerance, buffering, and a means

disclaimer: co-author of NSQ [1] here Agreed. Message queues play an important role for us (bitly) in being a layer of fault tolerance, buffering, and a means to perform various operational tasks. They're so important to us that we decided to build something that worked exactly like we wanted. NSQ is a realtime distributed message processing system where we've taken the approach of focussing on making it ops friendly and easy to get started. IMO, solutions that make it easy to develop on and administrate are most important... because things break. NSQ is straightforward to deploy (limit dependencies), simple to configure (runtime discovery), and client libraries provide a lot of functionality important for handling failures (like backoff, deferred messages, etc.) for a variety of use cases. We've written an in-depth introductory blog post [2] about NSQ that has more details. [1]: https://github.com/bitly/nsq https://github.com/bitly/nsq [2]: http://word.bitly.com/post/33232969144/nsq http://word.bitly.com/post/33232969144/nsq