Blog
News, releases and articles about @imqueue. Page 2 of 8.
Typed at compile time, unchecked on the wire: runtime validation for TypeScript services
Your service method has a signature. The message that arrives has none — it is JSON, and JSON does not remember what it was supposed to be. This is the story of the bug that leaves no stack trace, why your compiler was never in a position to catch it, and how to put a real check at the boundary without slowing anything down.
read →Autoscale on queue depth, not CPU
CPU tells you a process is busy, not whether anyone is waiting. An @imqueue service's backlog is a Redis list, so KEDA can scale on it with no exporter, no Prometheus and no code change — and the metrics server covers the case where you need more.
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 →Cache invalidation across services: a TTL, a tag, or the database
Caching a service method is one decorator. Deciding when the entry dies is the whole job. Here are the three mechanisms measured — a guessed TTL, a tag invalidated by an event, and PostgreSQL dropping the entry 6ms after the row changes — plus the four ways a cache goes on serving data it already knows is stale, and a fifth that got fixed while this was being written.
read →The N+1 problem when GraphQL resolvers call microservices
A field resolver runs once per parent object. Put a service call inside it and one innocent-looking query becomes twenty-six. Here is the same query measured at 26 calls and at 3, why your latency chart will not show you the difference, and the two ways the fix comes back silently empty.
read →