Blog
News, releases and articles about @imqueue. Page 1 of 10.
Compressing messages between Node.js services: zstd for the big ones, plain JSON for the rest
Most messages between your services are a few hundred bytes. A handful are reports, exports or month-long lists that weigh megabytes, and they are the ones that fill Redis when a consumer falls behind. @imqueue can compress just those with zstd. Here is what it saves, what it costs, where the size threshold belongs, and the rollout order that matters: a consumer that can't read zstd drops those messages for good. Every number is measured.
read →Deadlines for queued calls: stop doing work for callers who already gave up
When a service behind a queue goes down, its callers time out, but their calls don't disappear. They wait in the queue, and when the service comes back it works through every one of them. We took a billing service down for 20 seconds: the customers whose checkout said “payment failed” were all charged anyway, and every retried order was charged twice. Here is why that happens, the twenty lines that stop it, and what a queue does instead of a circuit breaker. Every number is measured.
read →Rate limiting a Node.js API across many instances, without letting a forged header ban your customers
A per-process rate limiter stops counting the moment you run a second copy of your API. Moving the counter into Redis fixes that, and exposes the question that matters more: who is the client? Here is how @imqueue/http-protect counts and bans across every instance, what the counter really measures, why trusting X-Forwarded-For lets anyone get your customers banned, and how to set it up so it can't. Every behaviour is measured.
read →Request IDs and user context across Node.js services, without adding a parameter to every method
A log line in your billing service says a charge failed. Which user? Which request? Billing cannot tell you, because nobody told it. Here is how to carry a request ID, the user and the tenant from the edge of your system through every service call it causes, read them anywhere in a handler, and pass them on automatically, plus the one place where that context must never decide the answer. Every behaviour is measured.
read →When Redis restarts: persistence, eviction and reconnects for a Node.js service fleet
Sooner or later the Redis under your services restarts: an upgrade, a moved node, a process killed for memory. Whether your queued messages are still there afterwards depends on three Redis settings most teams never chose, and what your services do in the meantime depends on how the framework reconnects. Here is what we measured on a real Redis, the five lines of configuration that decide it, and what to do in code for the seconds the broker is gone.
read →