// the find
nsqio/nsq
A realtime distributed messaging platform
NSQ is a battle-tested message queue written in Go, built around the idea that brokers should be dumb and clients should be smart. It trades ordering guarantees for operational simplicity — no Zookeeper, no external coordination layer, just nsqd nodes that consumers discover via nsqlookupd. In production at Stripe, Bitly, Fastly, and others for over a decade.
The topology model is genuinely elegant: nsqlookupd acts as a discovery layer only, so nsqd nodes are fully independent and you can lose any one without taking down the cluster. The at-least-once delivery with in-flight tracking and configurable requeue timeouts handles the 'what if the consumer crashes mid-processing' problem cleanly. Binary releases for all major platforms with zero runtime dependencies means you're running it in five minutes, not fighting a JVM or Python version matrix. The included utility programs (nsq_to_file, nsq_to_http, nsq_tail) are legitimately useful for debugging and one-off integrations without writing any code.
No message ordering within a topic — messages are delivered to consumers in roughly publish order but there's no guarantee, which eliminates NSQ from any use case where sequence matters. The admin UI is built on Backbone.js and Bootstrap 3; it works but hasn't been meaningfully updated in years and the frontend build tooling (Gulp, old Node ecosystem) is a liability if you ever need to modify it. There's no built-in dead-letter queue — failed messages that exhaust retries are just dropped unless you build that logic yourself in the consumer. Compared to Kafka or Pulsar, there's no message replay or consumer group offset management, so 'reprocess everything from 2 hours ago' is simply not a feature NSQ has.