rsmq: A Redis Message Queue for Node.js Applications

RSMQ's Place Beside Redis and Amazon SQS

RSMQ addresses a narrow queueing problem for Node.js developers who already have Redis but do not want to operate a dedicated message broker. It adds named queues, message identifiers, FIFO delivery, delayed delivery, visibility timeouts, and deletion-based acknowledgement to Redis. The README explicitly positions it as a possible replacement for Amazon SQS or a similar queue, although that is a functional comparison rather than evidence that it reproduces every SQS feature.

The intended users are applications that need several Node.js processes to exchange work through a shared Redis server. A producer can put a message into a queue, and a consumer can retrieve it, process it, and delete it by its returned identifier. Multiple workers can therefore share the same queue without adding another queue-server process.

RSMQ does not provide the wider service layer associated with a dedicated broker. Its package depends on `redis`, while worker helpers, a REST interface, a terminal client, and alternative Promise interfaces are separate modules. That separation keeps the core package focused, but it also means an application needing an HTTP queue API, a ready-made worker utility, or operational tooling must select and evaluate another package.

The project is particularly relevant for background jobs, work distribution, and delayed processing where the application's own delivery semantics are acceptable. It is less convincing as a default choice for a team that wants broker features without writing queue policies, retry coordination, or monitoring around them.

How RSMQ Stores and Redelivers Messages

RSMQ uses Redis as its queue store and executes its queue operations through the Redis `EVAL` command with Lua scripts. This atomic server-side execution matters because queue changes involve several pieces of state, such as the available-message list, hidden messages, queue counters, and timeouts. The README requires Redis 2.6 or later for this mechanism.

Messages are normally handled in first in, first out order. A queue can also define a delay, which postpones delivery of all new messages sent to that queue. This means strict FIFO order is not the right mental model when delay is enabled: a delayed earlier message is not ready while a later message may already be eligible, depending on the elapsed time.

Each sent message receives a unique `id`. The identifier returned by `sendMessage` can be used for deletion, and `receiveMessage` returns an identifier with the message and statistics. A received message becomes invisible to other receiving components for the queue's visibility timeout, `vt`. The default `vt` is 30 seconds. If the consumer does not delete the message before that timeout, it becomes eligible to be received again.

That behavior makes RSMQ closer to an at-least-once queue than a system that removes a job during delivery. Consumers should therefore account for the possibility of processing the same logical message more than once. The README states that delivery is guaranteed to exactly one recipient within the visibility timeout, but it also says undeleted messages reappear afterward. These statements describe competing phases of the same lifecycle, not permanent exactly-once processing.

Installing RSMQ and Creating a First Queue

RSMQ is installed from npm. The README requires Node.js 20 or later, while `package.json` declares `>=20.0.0`. A reachable Redis server is also required. After installation, construct the client with the Redis host and port. The README uses the default Redis address, `127.0.0.1` on port `6379`, and names the key namespace `rsmq`.

Install the package:

npm install rsmq

The command adds `rsmq` to the project. The project lists `redis` as its only runtime dependency, so npm will also install the Redis client required by RSMQ.

Create and inspect the client in a Node.js program:

const RedisSMQ = require("rsmq");
const rsmq = new RedisSMQ({host: "127.0.0.1", port: 6379, ns: "rsmq"});

This constructor uses the defaults documented for host, port, and namespace. RSMQ passes its `options` object to `redis.createClient`, so supported Redis options such as `db`, `tls`, and `retry_strategy` can be supplied there. An existing Redis client can also be passed through the `client` parameter.

Create a queue named `myqueue`:

rsmq.createQueue({ qname: "myqueue" }, function (err, resp) {
	if (err) {
		console.error(err)
		return
	}

	if (resp === 1) {
		console.log("queue created")
	}
});

A result of `1` means the queue was created. Queue names may contain up to 160 characters, with alphanumeric characters, hyphens, and underscores. The optional queue settings are `vt`, `delay`, and `maxsize`. The default message-size limit is 65536 bytes, while `-1` means unlimited according to the README.

Queue Controls and Their Visible Trade-offs

RSMQ exposes queue administration alongside message operations. `listQueues` returns queue names, `getQueueAttributes` returns settings and counters, and `deleteQueue` removes both the queue and all its messages. These controls are useful for a small service, although deleting a queue is destructive and irreversible through the documented API.

List the queues visible under the configured namespace:

rsmq.listQueues(function (err, queues) {
	if (err) {
		console.error(err)
		return
	}

	console.log("Active queues: " + queues.join( "," ) )
});

The callback receives an array such as `myqueue`. Queue attributes expose the visibility timeout, delivery delay, maximum message size, total messages received, total messages sent, creation and modification timestamps, current messages, and hidden messages. This gives an operator enough information to distinguish messages ready for delivery from those temporarily hidden after receipt.

The settings have wide ranges. Both `vt` and `delay` can range from 0 to 9999999 seconds, which the README describes as roughly 115 days. A long visibility timeout can postpone redelivery for a substantial period when a consumer fails to delete a message. A short timeout can make the same message available again while slow processing is still underway. Neither value automatically coordinates consumer-side retries.

The package can also publish new messages through Redis `PUBLISH` when its `realtime` constructor option is enabled, but that option defaults to `false`. The core README identifies realtime publication and links to a dedicated section, but the truncated API details supplied here do not define its event contract. Its production use should therefore be checked against the complete documentation.

RSMQ's Small Core and Separate Extension Modules

The repository presents RSMQ as a compact implementation of roughly 500 lines of JavaScript, with `redis` as the only runtime dependency. That is a deliberate architectural choice. Instead of bundling worker abstractions or network services, the README lists separate modules for common additions.

`rsmq-worker` is described as a helper for implementing a worker, while `rest-rsmq` provides a RESTful interface. Separate packages also provide a terminal client and Promise interfaces based on different approaches. TypeScript declarations are included in the published package, and the package metadata points the `types` field at `index.d.ts`.

This split can be an advantage when a service needs only Redis-backed queue operations. It also creates a selection cost. The core README does not imply that installing `rsmq` installs any of those extensions. A team considering the REST module must evaluate its own installation, configuration, compatibility, and maintenance rather than treating it as an inherent feature of this package.

The package includes development tooling for TypeScript, CoffeeScript, Mocha, linting, and test compilation. The documented npm test path builds the project, compiles the test source, checks typings, and runs Mocha. These repository scripts do not establish service-level or compatibility guarantees by themselves, but they show that compatibility testing is part of the project's development structure.

Maintenance, Releases, and the Node.js Upgrade Boundary

The repository is not archived, and its last push was on 2026-07-29. That is recent activity, although the listed release history is older and inconsistent with the package version: `package.json` declares version `0.13.0`, while the most recent listed release is v0.9.1 from 2018-07-06. The repository can therefore be active without having a corresponding published release entry in the available release history.

The clearest maintenance boundary is the Node.js requirement. RSMQ requires Node.js 20 or later, so adoption can force an application and its deployment platform to upgrade if they still run an older release. That is an application-level cost rather than merely an installation inconvenience, because runtime compatibility affects build images, CI workers, and supported deployment environments.

RSMQ depends on `redis` version `^3.1.2`. The constructor documentation points to that client's options object, so upgrading RSMQ does not remove the need to review the Redis client boundary used by the application. The README requires Redis 2.6 or later because queue operations rely on Redis `EVAL`.

The project uses the MIT license. The `LICENSE.md` file is included in the repository, and the package metadata records the same identifier. This means the project is presented under a permissive open-source license, but teams still need to review the actual license text and their own distribution obligations rather than relying only on the metadata label.

Where RSMQ Is the Wrong Queue

The clearest failure mode is slow or interrupted processing. Because a received message remains in Redis until it is deleted, it reappears after `vt`. If processing can exceed 30 seconds, the default visibility timeout is shorter than the work. Another consumer may then receive the same message. Extending `vt` reduces that particular window but creates longer retention after a worker crash, so consumers still need durable side effects or idempotent handling.

Deletion is also the only acknowledgement step documented for a received message. If an application deletes first and then performs irreversible work, a process failure after deletion can lose the work. If it performs the work and deletes later, it must tolerate redelivery. The project documents queue mechanics here, but it does not claim exactly-once end-to-end processing.

RSMQ is the wrong choice when a dedicated broker is required by policy or architecture. It is also a poor fit for FIFO guarantees when queue-level delay is enabled without an application design that accepts out-of-order readiness. The absence of a built-in REST API is not itself a defect, but applications that require one must choose and assess `rest-rsmq` separately.

Compared with Redis Streams, RSMQ exposes a queue-oriented model built around named queues, visibility timeouts, receive operations, and explicit deletion. The documentation does not describe a Redis Streams implementation, feature mapping, or migration procedure, so the practical choice depends on whether an application needs RSMQ's documented queue semantics or Redis's own newer data structures.

Editorial conclusion

Node.js applications that already operate Redis and need a compact background-message queue can adopt rsmq after verifying their Redis version, Lua support, failure handling, and tolerance for redelivery. Services that need broker-managed routing, long-running consumer acknowledgements, or a documented operating model beyond this small Redis-backed library should first assess whether RSMQ's visibility timeout model fits their requirements.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. smrchy/rsmq on GitHub