Blog
News, releases and articles about @imqueue. Page 3 of 8.
Distributed tracing for Node.js services over a message queue
The standard objection to queue-based RPC is that you lose the trace: the caller sends, something else picks it up, and the connection between them is gone. It isn't — the trace context rides in the request metadata. Here is a measured three-process trace, and the four ways it silently comes out wrong.
read →@imqueue vs NATS: a framework and a transport are not the same choice
NATS is a messaging system; @imqueue is an RPC framework that happens to use one. Comparing them means deciding how much of the contract you want to write yourself — and whether your fleet is Node-only.
read →How Node.js services talk to each other in 2026: the honest options
REST, gRPC, tRPC, NATS, a framework like NestJS or Moleculer, or RPC over a message queue. Six real approaches, what each one costs, and the two questions that actually decide it — including when @imqueue is the wrong answer.
read →One notification, every replica: the LISTEN/NOTIFY duplicate problem
LISTEN/NOTIFY is a broadcast, not a queue. Scale a Node app to three replicas and the same notification gets handled three times — no error, no warning, three charges on the card. Here's why, and what an inter-process lock actually does about it.
read →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 built-in drain that keeps it.
read →