A simple high-performance Redis message queue for Node.js with multiple queue types, scheduling, and a web UI.
RedisSMQ is a high-performance message queue system built on Redis for Node.js applications. It enables reliable background job processing, task scheduling, and communication between microservices with features like retries, multiple queue types, and a built-in scheduler. It solves the need for a scalable and simple message queue that leverages Redis's speed and atomic operations.
Node.js developers building applications that require background job processing, microservices communication, or task scheduling with reliability and performance. It's also suitable for teams needing a self-hosted message queue with monitoring capabilities.
Developers choose RedisSMQ for its simplicity, high performance through Redis atomic scripts, and comprehensive feature set including scheduling, multiple queue types, and a web UI. It offers a clean TypeScript-first API with dual promise/callback support, making it flexible and easy to integrate.
A simple high-performance Redis message queue for Node.js.
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Uses atomic Lua scripts and batch acknowledgments to minimize Redis calls, achieving up to 99% fewer Redis operations as documented in the performance guide.
Supports delays, CRON jobs, and repeating messages natively, eliminating the need for external schedulers for task management.
Includes a Web UI and REST API with OpenAPI documentation for real-time monitoring, queue control, and message inspection.
Offers dual promise and callback support with full TypeScript typing, making it adaptable to various coding styles and modern Node.js workflows.
Ensures processing with configurable retries, TTL, and consumption timeouts, providing fault tolerance for critical background jobs.
Requires a separate Redis instance and client library (ioredis or @redis/client), adding operational overhead and potential single points of failure.
Limited to Node.js applications, making it unsuitable for polyglot environments without additional bridging through the REST API, which may introduce latency.
Demands explicit Redis client configuration and multi-package installation with version matching, increasing setup time compared to simpler queue solutions.
Primary documentation targets the 'next' branch for new features, which may introduce breaking changes or bugs not present in the stable 'master' branch.