Message queues
Articles on running Node.js services over a message queue: work queues, competing consumers, guaranteed delivery, back-pressure, and Redis as the broker.
13 articles
Graceful shutdown and zero-drop deploys
Every deploy sends a kill signal to a process that is probably in the middle of something. Nothing 500s, no dashboard turns red, and the work is gone anyway. Here's what actually happens to an in-flight message on SIGTERM, and the drain that keeps it.
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 →Auto-scaling Redis broker: with and without broadcast
One Redis behind your message bus is a ceiling and a single point of failure. The promoter and unicaster modules turn a fleet of plain Redis instances into a horizontally auto-scaling broker — here are the recipes for networks that deliver broadcast and for clouds like GCP that don't.
read →RPC over Redis in Node.js: patterns and pitfalls
How request/reply RPC over Redis actually works in Node.js — the correlation, timeout and delivery problems you have to solve yourself, why the old npm packages stalled, and how @imqueue turns it into typed, boilerplate-free calls.
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 →RPC between Node.js microservices over a message queue
Why route internal service-to-service calls through a message queue instead of HTTP or gRPC — and how @imqueue makes those calls fully typed with zero client boilerplate.
read →Load balancing microservices without a load balancer
For internal service-to-service traffic, the load balancer you run and operate is often solving a problem a message queue solves for free. Here's the competing-consumers pattern and what it removes.
read →Do your Node.js back-ends really need service discovery?
Consul, etcd, DNS-SD — service discovery is a lot of machinery to stand up. Sometimes you genuinely need it; often you don't. Here's how to tell, and how a queue makes the question disappear.
read →Back-pressure for Node.js services
When a downstream service slows down, HTTP tends to turn that into a cascading failure. A queue absorbs the spike instead. Here's the difference, and the trade-offs to watch.
read →Guaranteed message delivery: cost and when to use it
"Will I lose messages if a worker dies?" is the right question — and the answer is a trade-off, not a yes/no. Here's how guaranteed delivery works, what it costs, and how to choose per workload.
read →Redis as a message bus: patterns beyond pub/sub
Most people know Redis pub/sub and stop there. Redis has richer primitives — lists, blocking pops, and streams — that make it a capable message bus. Here's a tour, and where each fits.
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 →Benchmarking @imqueue: throughput and delivery modes
Real measured throughput for @imqueue's message queue — ~200k msg/sec unreliable, ~120k guaranteed on a 24-core box — what the delivery modes cost, and a reproducible harness to measure the figures that matter: yours.
read →