Jobs & scheduling
Articles on background jobs and background tasks in Node.js and nodejs services: delayed calls, scheduled work, retry backoff, recurring sweeps, and how @imqueue/job compares with BullMQ.
5 articles
Guaranteed delivery, tested with kill -9: what at-least-once actually promises when a worker dies
"Will I lose messages if a worker dies?" is the right question, and for a year this page answered it wrong. Here is what guaranteed (at-least-once) delivery really promises — measured by killing workers mid-job — what the one deadline actually governs, what a drain does and doesn't save, what it costs, and how to choose per workload.
read →Nothing threw, and the job never ran: silent failures in a Node.js message queue
A send() that resolves with a message id nobody will ever deliver. A push() that returns cleanly onto a queue redis refused to write. Neither throws, and neither can — the caller has already moved on by the time redis answers. That silence is over: here is what each of those failures now writes to the log instead, and the one upgrade note that costs you a stack trace.
read →Delayed and scheduled work without adding a job system
"Send that email in 24 hours" usually turns into a second deployment, a second data model, and a job record shadowing a service method you already wrote. Often the message queue you already run can just do it. Here's how deferral works as a parameter, and what it costs.
read →BullMQ alternatives for Node.js: an honest 2026 guide
BullMQ is the default Redis job queue for Node.js — but it isn't the only choice. Here's an even-handed map of the alternatives (Bee-Queue, pg-boss, Agenda, @imqueue/job and more), what each is actually good at, and how to pick.
read →@imqueue/job vs BullMQ: Redis job queues compared
Both are Redis-backed job queues for Node.js. @imqueue/job is small, safe-by-default and scheduling-capable; BullMQ is the feature-rich one. Here's an honest split — plus the thing @imqueue does that BullMQ doesn't.
read →