NSQ – A realtime distributed messaging platform

Is there anywhere I can read about the specific problem at bitly you built it to facilitate? I mean, I've seen a lot of these systems where there are integration and timing concerns, so some kind of message bus is useful. But if they do get to a point where things needs to be distributed, sending messages without order and delivery guarantees just seems to be passing the buck to downstream systems to not mess up.

For different applications differently delivery QoSes are tolerable. For instance, if your messages are idempotent (either by design or nature) then "at least once" is equivalent to "exactly once" and may be much faster/easier.

Generally, "exactly once" demands the least of the application and the most of the broker.

[0] I suppose you could have "any number of times" as well, but that's no guarantee at all.

However, it is a benefit in that allowing for more-than-once-delivery affords better performance. Think of it from an algorithmic perspective: if you want to send a message exactly once, you have to wait around for acknowledgement that your message was accepted.

If you instead don't mind sending duplicates, you can fire off the first copy, wait for an ack for a while, and then fire off again to another node (in case, perhaps, there was a network partition). If it turns out that both copies arrive at their final destination intact, your application now has to deal with duplicates. But, that's faster than the alternative.

So it puts more burden on the developer to deduplicate where necessary (or program in a model where duplicates don't matter anyway, such as with CRDTS), in exchange for greater throughput.

It's super easy to run. A few command line params, if that, and I've got a local nsqd running that I can develop and test against. Great for those offline coding sessions on BART.

The tools it ships with are very handy, specifically to_nsq and nsq_tail. Again, both make developing stuff really easy because I can get stuff in and out with fast, native command line tools or http. In fact, when I was first playing around I built an entire prototype based on a few simple shell scripts and the provided tools, just to see what would happen.

The nsqadmin and nsq_stat tools give you a lot of visibility into what your producers and consumers are doing, how well things are performing, who is connected to what, etc. And again, part of the distribution and very easy to run locally.

The Go producer and consumer API is clean and easy to build around, pretty well documented with a lot of examples in the NSQ apps themselves.

So far very stable. I haven't seen any crashes on the server or producer/consumer side.

Helpful and friendly people on a low noise freenode channel.