An NSQ system consists of the following components:

• The virtual topic construct: Topics are the destination for messages being produced in NSQ. Each topic has one or more Channels, which are the queues for each consumer, thereby enabling Pub/Sub behavior. Topics and Channels are implicitly created on first use.
• nsqd: This is the main component; it receives, queues, and delivers messages to clients. It can run as a daemon or can be embedded inside a Go application. This can run standalone, but is normally configured in a cluster with nsqlookupd. These instances host multiple Topics (for all connected clients that produced messages) and Channels for all the Topics. The relationship between Topics, Channels, and nsqd is depicted in the following diagram:

• nsqlookupd: This is the daemon that has the overall cluster picture and manages the topology. Clients query nsqlookupd instances to discover different nsqd instances that host messages (are the producers) for a specific topic. Its main job is to provide a directory service where clients (consumers) can look up the addresses of nsqd instances that host the Topics they are interested in consuming from.

Each nsqd instance has a long-lived TCP connection to nsqlookupd over which it pushes its state (such as health or topics). This is collated and then used by nsqlookupd to give the right set of nsqd instances to clients wishing to consume a specific topic. nsqd and nsqlookupd instances operate independently, without peer communication. For nsqlookupd, high availability is achieved by running multiple independent instances. Clients sum's poll all of their configured nsqlookupd instances and unit the responses.

Clients connect directly to nsqd instances, as shown here:

It should be noted that messages for a Topic might be available at more than one nsqd instances, and a client will connect to all nsqd instances hosting messages for a Topic.

When a client connects to an nsqd instance, the exchange is as follows:

1. The Client indicates it is ready to receive messages. Instead of a binary signal, the client sends a value, called RDY state, which indicates how many messages the client is ready to receive.
2. nsqd sends a message and temporarily moves the data to another local store (if retransmission is needed).
3. After consumption of the message, the client in the event of a re-queue client replies with a FIN (finish) packet and this message is then dropped by the producing nsqd instance's channel. If the client had an error, it can request the message again using a REQ (re-queue) packet.

4. nsqd runs a timeout after sending a message and, if there is no response, will automatically re-queue the message:

NSQ can store messages in memory and flush them to disk based on a configurable watermark. If durability for all messages is required, this configuration can be set so that messages are always written to disk. To achieve high availability, clients can write to more than one nsqd instance (this assumes that consumers are idempotent).