Blog
News, releases and articles about @imqueue. Page 4 of 8.
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 →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, and how to encrypt the result when the brokers announce addresses no certificate can carry.
read →One isolated imq CLI home per @imqueue project
Every imq invocation shares one ~/.imq — one config, one pid registry, one set of logs. Here's how to give each project its own isolated CLI environment with IMQ_CLI_HOME, plus recipes for direnv, shell wrappers, per-client tokens and disposable sandboxes.
read →RPC over Redis in Node.js: patterns and pitfalls
How request/reply RPC over Redis actually works in Node.js — correlation, timeouts and at-least-once delivery, which of those @imqueue handles for you, and what it deliberately leaves to you: retrying a failed RPC call, coalescing duplicate concurrent calls with @lock, and the circuit breaker it does not ship.
read →