Message delivery
Articles on message delivery guarantees: guaranteed versus unreliable delivery, what each costs in throughput, and delayed or scheduled delivery.
6 articles
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 →Guaranteed delivery, tested with kill -9: what at-least-once actually promises when a worker dies
"Will I lose messages if a worker dies?" is the right question, and for a year this page answered it wrong. Here is what guaranteed (at-least-once) delivery really promises — measured by killing workers mid-job — what the one deadline actually governs, what a drain does and doesn't save, what it costs, and how to choose per workload.
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 →@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 →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 →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 →