Does NSQ Remember Between Runs? Messages Copy to Every Channel. The Next Run Still Starts With Only Its Message.

NSQ is a realtime distributed messaging platform. A publisher sends a message to a topic, every channel on that topic receives a copy, and consumers take messages from a channel. For a team whose consumers do AI work on a schedule, that raises a practical question: when the same kind of message arrives again tomorrow, does the consumer know anything about today's run? No. NSQ holds each message exactly as it was published, as a body waiting in a topic and its channels. The next message still starts with only what its publisher wrote into it. What the last run found is not passed along.

A topic copies the message, and no copy learns from the others

Streams in NSQ are called topics, and a topic has one or more channels. Topics and channels are not configured in advance. A topic is created on first use by publishing to it or by subscribing to a channel on it, and a channel is created on first use by subscribing to it. Each channel receives a copy of all the messages for its topic. In practice, a channel maps to a downstream service consuming that topic.

That copy rule is multicast at the top and distribution underneath. Inside a channel, each message is distributed among its connected consumers, so each consumer receives a portion of the channel's messages. Topics and channels also buffer data independently, so a slow consumer on one channel does not create a backlog for other channels.

Routing and copying decide where a message waits and who can take it. They do not decide what the message knows. Two channels can receive copies of the same message and reach opposite conclusions about it, and NSQ records neither conclusion. The tree of topics and channels organizes streams. It does not organize what a stream learned.

FIN ends the message, and its result goes nowhere

Delivery in NSQ is guaranteed at least once, and duplicate messages are possible, so consumers are expected to deduplicate or perform idempotent operations. The guarantee is enforced in the protocol itself. The client indicates it is ready to receive messages, NSQ sends a message and temporarily stores the data locally in the event of a requeue or a timeout, and the client replies with FIN to finish the message or REQ to requeue it. If the client does not reply, NSQ times out after a configurable duration and automatically requeues the message.

Each of those endings answers a delivery question only. FIN means this message is done, and the message leaves the channel. REQ means this message should be tried again, and the same message returns, unchanged. A timeout means no answer arrived in time, and again the same message returns, unchanged. None of them creates a result record that the next message can read. There is no summary field filled in by the consumer, no decision merged into the topic, and no note attached to tomorrow's message saying what today's consumer checked.

A requeued message is not a smarter message. It is the original body delivered again, to a consumer that has to work out from the body alone whether part of the job was already done.

Messages live in memory first, and overflow goes to disk

NSQ is primarily an in-memory platform. A configuration option on the daemon that receives, queues, and delivers messages, nsqd, called mem-queue-size, determines how many messages are kept in memory for a given topic or channel, with a default of 10,000. Messages beyond that high-water mark are transparently written to disk through a disk-backed queue. Setting mem-queue-size to 0 ensures that all incoming messages are written to disk instead.

That design keeps the memory footprint of a single nsqd process bounded while waiting work waits. It does not turn completed work into memory. A message held on disk is still the published body, waiting for a first or another delivery. Once a consumer finishes it, that stored copy is gone, and the consumer's findings are not written back into the disk queue for a successor to find.

Ephemeral channels underline the same boundary. An ephemeral channel discards overflow rather than writing it to disk, and it disappears when its last consumer disconnects. NSQ optimizes for moving messages to consumers now, not building a history that later consumers can search. The lookup daemon manages topology and discovery, and the admin interface shows the cluster in realtime. Neither answers what a consumer decided yesterday.

Consider a scheduled AI consumer subscribed to a channel for product feedback. On Monday it groups a batch by theme, flags two as repeats of a known request, and drafts replies for each sender. On Tuesday new messages arrive with the same themes. Without an outside memory, the consumer groups them from scratch and can flag the known request as new again. The delivery is correct. The work is repeated, because each message arrives alone.

Watch: Liam and Stella break this down on Agentic Pod, with the full technical guide on GitHub.

What a scheduled NSQ consumer actually needs

The missing piece is not a better topic layout. NSQ already does the messaging job well: simple topics and channels created on first use, copies for separate services, load distribution inside a channel, at-least-once delivery with FIN, REQ, and timeout handling, and bounded memory with disk overflow for waiting messages. The missing piece is a memory that sits outside any single message, that a consumer can read before it acts and write to when it finishes, and that every other tool in the workflow can also reach.

That memory is what Vilix AI provides as a shared memory layer. Vilix AI is cloud-hosted, so there is zero infrastructure to run or maintain: no extra database to provision and no memory service to deploy next to nsqd. The same memory is available everywhere over MCP, so the consumer that takes the message, the chat tool used to review its output, and every other connected agent read and write one shared memory instead of separate local notes. And Vilix AI stores full conversation history, not just extracted facts, so a run can revisit what was actually said and decided, in context, rather than working from a compressed summary.

With that layer in place, the Tuesday consumer changes shape. Before it groups anything, it loads what Monday's run saved: which themes were already grouped, which requests were already known, and which replies were already drafted and why. It spends its time on what is new, then saves its own findings back, so Wednesday's run starts briefed as well. The channel still delivers the message. The memory delivers the briefing.

Vilix AI is free forever on the free plan, and the 7-day Pro trial needs no credit card. Everything saved can be exported or deleted at any time. For a scheduled consumer that redoes finished work, give the next message the last run's memory and watch repetition disappear.

NSQ will keep copying each message to every channel unchanged. The question is only whether the consumer arrives alone. With a shared memory layer beside the platform, it arrives knowing what the run before it learned.