Loading content
BullMQ is a Node.js library for reliable background job processing using Redis. It implements priority queues, delayed jobs, retries, events and rate limiting, and provides fine-grained concurrency control to support scalable worker architectures. Deployments can be scaled horizontally; idempotent handlers are recommended for repeatable jobs.
Use this profile to understand the building block briefly, place it in the model, and open related building blocks.
Technical building block: can be automated, integrated, or operated.
Concrete cog in the system that works inside larger relationships.
BullMQ is a Node.js library for reliable background processing on Redis. It organizes jobs in queues and supports repeatable, delayed, and prioritized tasks with distributed workers.
BullMQ was developed by Taskforce.sh Inc. as a Redis-backed Node.js queue for reliable background processing. Its documentation targets distributed microservice workloads with horizontal scaling, retries, crash recovery, and high throughput; the GitHub repository and MIT notice identify Taskforce.sh Inc. as the authoring organization.
Think of BullMQ as a control layer between the application, Redis, and many workers. The application places a job with data and rules into a queue. Redis keeps it ordered and available, a worker picks it up, executes it, and reports success or failure back. Options such as priorities, delays, retries, concurrency, and rate limits decide when and how fast jobs run. Repeated execution requires idempotent handler behavior.
Tasks run asynchronously through a queue and workers so requests do not wait for long-running work.
Priorities and FIFO/LIFO behavior determine which jobs are processed first.
Failed or scheduled jobs can run again later or after a defined delay.
Parallelism and execution speed can be constrained to protect workers and dependent systems.
Running the same job more than once should lead to the same business state without duplicate side effects.
BullMQ is useful when an application should respond quickly and do the real work later, such as sending emails, handling webhooks, processing imports, or running media jobs. It fits horizontally scaled worker architectures, but it still requires Redis, careful failure handling, and idempotent jobs. It is not a substitute for transaction logic and does not provide magic guarantees of strict exactly-once execution or hard real-time behavior.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.