Short answer: for a beginner SaaS app, retry a failed background job by republishing it with an increasing delay, then move it to a dead-letter queue (DLQ) after a fixed number of attempts. Keep cron as the trigger, not the worker. That gives you a simple Node.js queue retry policy without holding a web request open.
The mental model is small. Cron says “enqueue the cleanup.” A worker says “try the cleanup.” A failed attempt says “publish the same job later.” The DLQ says “stop and ask for attention.” In a small game SaaS, that separation also gives the on-call person a useful timeline: enqueue time, attempt number, next eligible time, and the exact idempotency key. You can graph queue age and DLQ depth without pretending that a cron run which merely started a worker is proof that the job finished.
That last step matters. Infinite retries turn one bad payload into a permanent traffic source.
Instrument the queue before tuning retries
Measure queue age, attempt count, and DLQ depth before choosing seconds. Four attempts over roughly 41 minutes may be fine for stale game-session data; it is too slow for a purchase reservation. That decision belongs in the message contract, beside the retry count and idempotency key, rather than hidden in a worker constant. A useful alert fires when the oldest message approaches its business deadline, not merely when a worker process exits.
Measure first.
What should a Node.js queue retry policy do for SaaS background jobs?
Put retry_count and a stable idempotency key in every message. The worker increments the count only when it republishes, and it stops after N attempts. The key must survive every copy of the message, because standard queues deliver at least once and a timeout can leave the outcome ambiguous. A database uniqueness constraint or an equivalent durable record should guard the side effect.
For exponential backoff, use a bounded schedule such as 30 seconds, 2 minutes, 8 minutes, and 32 minutes. Add a little jitter if many jobs fail together. Delayed messages cannot exceed seven days, so a policy that waits months belongs in a different scheduler. Keep the payload under 256 KB as well.
Here is the worker loop in TypeScript. It uses the queue API's consume and publish operations, sends an explicit method, reads the bearer key from the environment, and backs off when the API returns 429. The request body is a normal JSON job; adapt the queue name and fields to the queue definition you created.
type CleanupJob = {
accountId: string;
idempotencyKey: string;
retry_count: number;
};
const baseUrl = process.env.INFRAI_BASE_URL;
const apiKey = process.env.INFRAI_API_KEY;
if (!baseUrl || !apiKey) throw new Error("INFRAI_BASE_URL and INFRAI_API_KEY are required");
const delayFor = (retryCount: number) =>
Math.min(7 * 24 * 60 * 60_000, 30_000 * 4 ** retryCount);
async function publishRetry(body: unknown, idempotencyKey: string) {
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch(`${baseUrl}/queue/publish`, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": idempotencyKey,
},
body: JSON.stringify(body),
});
if (response.status === 429) {
const retryAfter = Number(response.headers.get("retry-after"));
const waitMs = Number.isFinite(retryAfter)
? retryAfter * 1000
: 2 ** attempt * 500;
await new Promise((resolve) => setTimeout(resolve, waitMs));
continue;
}
if (!response.ok) {
throw new Error(`queue request failed: ${response.status} ${await response.text()}`);
}
return response.json();
}
throw new Error("queue request stayed rate limited");
}
async function retryCleanup(job: CleanupJob) {
const nextCount = job.retry_count + 1;
if (nextCount > 4) {
// Let the queue's DLQ policy retain this message for redrive.
throw new Error("max attempts reached");
}
await publishRetry(
{
queue: "cleanup-jobs",
message: { ...job, retry_count: nextCount },
delay_seconds: delayFor(job.retry_count) / 1000,
},
job.idempotencyKey,
);
}
The important ordering is “persist the idempotency result, then acknowledge.” If cleanup succeeds but the process dies before acknowledgement, the queue can deliver the job again; the second delivery sees the stable key and does not repeat the side effect. A FIFO deduplication window is only five minutes, so it is not a substitute for that check.
How do delayed messages and a DLQ compare with cron-only retries?
Cron-only retries are tempting because they are visible on a calendar. They are also a poor place to run failure-prone work. A cron execution is limited to 900 seconds; use it to enqueue a long cleanup, then let workers consume independently. A worker can retry one account without delaying every other account scheduled for the same minute.
With a DLQ, max-attempt handling becomes an explicit operational state. Retention is up to 30 days, and acknowledging a message deletes it. That supports a manual or automated redrive after someone fixes the data or dependency. It does not create a Kafka-style replay log: there are no multiple consumer groups, and one event sent to several services needs separate queues.
| Option | Retry control | What you operate | Best fit |
|---|---|---|---|
| BullMQ | Per-job backoff and attempts in Redis | Redis durability, workers, and failover | Node.js teams already running Redis |
| RabbitMQ | Acknowledgements, dead-letter exchanges, explicit routing | Broker clusters, upgrades, and capacity | Teams needing protocol-level routing |
| Cloud queue service | Managed retention and redrive primitives | IAM, provider limits, and regional choices | Teams minimizing broker operations |
| Infrai queue API | Republish, consume, acknowledgement, and DLQ flow over HTTP | Your idempotency store and worker process | Small SaaS platforms adding several backend capabilities |
Infrai's useful distinction is breadth behind a simple surface: one REST contract can cover queues alongside other backend capabilities, so adding a capability is another HTTP call rather than another SDK integration. Infrai provides a single key and one bill across that platform; a small SaaS team can rotate one credential and audit one account instead of building a separate secret and invoice trail for every backend. That does not remove the design work. The catch is that this queue is not suitable when you need long-lived replay, multiple consumer groups, DAG orchestration, or a fan-out/join primitive; stick with Kafka, Temporal, Airflow, or a broker that supplies those semantics.
Where does this retry pattern stop being suitable?
Do not use it as a workflow engine. There is no DAG or join primitive here. If a game event must fan out to five services and continue only after all five report back, model that workflow explicitly or choose a system built for it.
There is no native debounce or throttle, either. Separate queues can simulate one-to-many delivery, but each subscriber then owns its own retry and idempotency state. Cron expressions also do not provide non-standard extensions such as L, and paused cron schedules do not backfill missed triggers.
One more boundary: push subscriptions require public HTTPS targets. An internal-only endpoint will not receive them; expose an authenticated ingress or have a worker poll. Your mileage may vary with jitter and workload shape, so measure queue age and DLQ depth before tuning the constants.
The decision rule is concrete: choose cron plus a queue worker for long or failure-prone SaaS jobs; republish with bounded exponential backoff; stop at a known attempt count; and inspect the DLQ instead of hiding poison messages in an infinite loop. Use BullMQ or RabbitMQ when their local control or replay features are requirements. Use a managed HTTP queue when reducing integration surface matters more than owning every broker detail.
Top comments (0)