|
|
|
|
|
|
by matticakes
4155 days ago
|
|
|
(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 was designed to replace an existing home-grown system deployed at scale. This dictated a lot of the initial requirements (and in certain cases excluded off-the-shelf tools). When we left the experimental phase we realized we had built something that was useful to others, and it turns out that despite not having the features you've identified it can be incredibly effective in lots of use cases that don't need stronger guarantees. [1] If I'm being honest, NSQ was a vehicle for adoption of Go at bitly as well as the project we used to learn the language. This was a huge risk at the time (almost 3 years ago) but one that has certainly paid off. |
|
|
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.