Viewing profile — matticakes

I'm one of the original authors, happy to answer any questions.

NSQ is a full-featured messaging platform out-of-the-box, whereas zeromq and nanomsq are lower level libraries that you could use to build (the same) functionality.

You can embed the daemon into your application. That sentence is missing an important word. No centralized brokers, meaning the typical/recommended deployment topology is an nsqd n…

Thanks! This is something that I've always tried to stress when talking about NSQ... The "message queue" is the most boring and uninteresting aspect of the system. It's the combina…

Yea, in the original announcement blog post (which became the design doc): http://nsq.io/overview/design.html

(project author) I appreciate all the work that Tyler has put into his series of blog posts on messaging systems (and NSQ bug reports!) but I think this particular article is one t…

(project author) NSQ is as much about what it doesn't do as it is what it does. To a certain extent this mirrors, and was inspired by, the language's philosophy (Go) [1]. Also, NSQ…

check out NSQ, designed for (in part) exactly this use case (and also written in Go) http://bitly.github.io/nsq

NSQ treats the message data as an opaque blob so the format wouldn't directly affect it (except on some lower level related to overall message size I suppose). It would impact your…

there are a few (growing) number of production installations of NSQ... our (bitly's) cluster spans a a few datacenters and hits peaks of 80k messages/second. I can answer any quest…

You can swap out the "metrics system" described in the post with any downstream system. I have a lot of experience with NSQ but have not used NewRelic. I can answer any specific qu…

Thanks. For the record... NSQ is a generic messaging platform and is data format agnostic, there is nothing specific about metrics collection (it was just my contrived example).

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 op…

It's a bit more explicit in NSQ but we essentially support multicast-like routing through "channels". A "channel" receives a copy (at the source) of all the messages for a "topic" …

The focal point is discovery. Not other queues (or other libraries that can build queues). This is an interesting way to approach it, thanks for open sourcing. We chose to solve th…

The truth is we wanted to use ZeroMQ initially. It would have been really awesome to have all that flexibility on the client side. The ZeroMQ documentation is fantastic as well. It…

That's fair, you certainly can use rabbitmq in a distributed and decentralized fashion. You bring up an important point though... What is important is the topology we're promoting …

We looked into AMQP based solutions. Our understanding is that slaving, master-slave failover, or other strategies are used to mitigate the fact that there is a broker responsible …

beanstalkd is a great project and it certainly inspired some of our thinking. I think of beanstalkd as a more fully functional alternative to simplequeue (what we built/used prior …

Agreed, a comparison would be helpful for highlighting the tradeoffs behind the choices we made. We do talk about the evolution of our infrastructure and the genesis of NSQ in our …

it is data format agnostic so you can certainly serialize using the gob package.

one of the developers here... The protocols that exist in NSQ now are designed to be the simplest implementation that worked. You've correctly pointed out some of the issues. At th…