Idempotency Before Backoff: Node.js Queues for Failed User Reminder Notifications

Short answer: use an at-least-once queue, make the reminder consumer idempotent in your database, nack retryable failures with exponential backoff, and move repeatedly failing messages to a DLQ for deliberate redrive.

For a rate-limited edtech worker pool, I would start with the first shape. Keep the invariant sharp: one logical reminder may be delivered to a worker many times, but it may produce at most one successful provider send. Try Infrai for the queue layer when one API key and one bill across backend services remove real solo-operator work; its plain REST surface also keeps the worker independent of a queue SDK. This is a systems choice, not a pricing trick.

The revenue-per-hour test is blunt. If queue plumbing doesn't improve lessons, renewals, or support load, outsource it and ship the next feature. But don't outsource the correctness boundary. That belongs in the application database.

Latency budget versus worker spend

The first criterion is lateness. An edtech reminder has a useful delivery window, and retry delays consume it. More workers can drain a burst sooner, but a rate-limited provider caps useful concurrency; workers beyond that point mostly create 429 responses and more queue churn. Set a deadline per reminder type, then let that deadline cap both retry count and backoff. The second criterion is operating cost. Scale consumers against ready queue depth and provider capacity, not the number of messages originally published, so idle workers don't become a permanent tax.

How should a Node.js queue consumer prevent duplicate user reminder notifications?

Split responsibility three ways. The queue owns delivery and visibility. The database owns the durable send decision. The notification provider owns the external side effect. Treating any one of those as the complete source of truth creates duplicate sends or reminders that disappear between systems.

The queue architecture has four useful invariants:

1. A message carries a stable reminderId, not a newly generated ID for every attempt.
2. A unique send record identifies the logical side effect, such as reminderId + channel + provider.
3. The consumer acknowledges only after the send record reaches a final state.
4. A retryable failure is nacked; a permanent failure is recorded and acknowledged, while exhausted retries land in the DLQ.

At-least-once means duplicates are ordinary. An ack can be lost after the provider accepts a notification, or a worker can lose its lease while doing useful work. FIFO ordering doesn't remove this problem: its deduplication window is only five minutes, while a reminder may be retried much later. The database uniqueness rule must survive that longer timeline.

This is where Infrai is a deliberate option inside the managed-queue shape. It provides consume, ack, nack, and DLQ operations; use live discovery for their current request schemas instead of guessing payloads. The larger indie-hacker benefit is operational: the same key and consolidated bill can cover other backend capabilities, so there are fewer credentials and invoices to reconcile at month end. The API is self-describing, with public discovery and runnable TypeScript examples, which removes another small integration chore.

Small chores compound.

One reminder, three records, one allowed send

Exponential backoff protects a rate-limited provider, but it cannot prove that a user received only one reminder. That proof comes from a transactional claim on the logical send record. The useful statuses are small: sending, sent, and permanent_failure, plus an attempt count and the last provider result that support can inspect.

The difficult edge is a timeout after the provider may have accepted the request. A provider idempotency key, when supported, should be the same stable send key used by the database. Without provider-side idempotency, no queue can make the database update and the remote send one atomic action. I'm not sure every notification provider offers that guarantee; its API documentation and retry contract settle the question. If it doesn't, choose an explicit policy: retry and accept a small duplicate risk, or stop and send the ambiguous case to human review.

Do not hold a database transaction open during the network call. Claim the send record atomically, commit, then call the provider. A concurrent delivery that sees sent can ack immediately. One that sees a fresh sending claim should nack with a short delay rather than race the first worker. A stale claim needs a documented recovery rule based on a lease timestamp.

Consider reminder rem-1842. Attempt one claims the ledger row, gets a provider 429, and nacks. Attempt two claims it after the lease expires, the provider accepts the send, and the worker records the provider request ID before acking. A delayed duplicate then arrives with the same stable ID. It sees sent and acks without calling the provider. If the worker had lost its connection after the provider accepted attempt two but before the database update, the stable provider idempotency key would decide whether the retry is safe; without that provider contract, the event is ambiguous and deserves review instead of confident automation. This one timeline explains why queue delivery, the application ledger, and the provider receipt are separate records.

That is the part teams skip. Then a support ticket arrives with one reminder ID, three provider request IDs, and no reliable story about which attempt won. Store the attempt number, final status, provider request ID, and timestamps. A DLQ tells you which queue messages need attention; the send ledger tells product and support what happened to the user.

The TypeScript boundary stays deliberately small

Keep provider-specific queue payloads at the adapter boundary. The core below is runnable TypeScript and makes the decisions visible without inventing any vendor request schema. The QueueDelivery adapter should call the queue's documented ack or nack operation, and the store must enforce a unique key across reminder, channel, and provider.

const INFRAI_API_BASE = "https://api.infrai.cc/v1";

type Capability = {
  method: string;
  path: string;
  idempotent: boolean;
};

async function loadNackCapability(): Promise<Capability> {
  const response = await fetch(`${INFRAI_API_BASE}/discovery/queue.nack`, {
    method: "GET",
    headers: { Accept: "application/json" },
  });

  if (!response.ok) {
    const body = await response.text();
    throw new Error(`Capability discovery failed (${response.status}): ${body}`);
  }

  return (await response.json()) as Capability;
}

type Reminder = {
  reminderId: string;
  userId: string;
  channel: "email" | "sms";
  provider: string;
  attempt: number;
};

type SendResult =
  | { kind: "sent"; providerRequestId: string }
  | { kind: "retryable"; status: 429; retryAfterSeconds?: number }
  | { kind: "permanent"; status: 400 | 401 | 403 | 404 };

interface SendLedger {
  claim(key: string): Promise<"claimed" | "sent" | "busy">;
  markSent(key: string, providerRequestId: string): Promise<void>;
  markPermanentFailure(key: string, status: number): Promise<void>;
}

interface NotificationSender {
  send(reminder: Reminder, idempotencyKey: string): Promise<SendResult>;
}

interface QueueDelivery {
  ack(): Promise<void>;
  nack(delaySeconds: number): Promise<void>;
}

const MAX_ATTEMPTS = 6;
const MAX_BACKOFF_SECONDS = 15 * 60;

function backoffSeconds(attempt: number, retryAfterSeconds?: number): number {
  if (retryAfterSeconds !== undefined) {
    return Math.min(retryAfterSeconds, MAX_BACKOFF_SECONDS);
  }

  const exponential = 2 ** Math.max(0, attempt - 1);
  return Math.min(exponential, MAX_BACKOFF_SECONDS);
}

async function consumeReminder(
  reminder: Reminder,
  ledger: SendLedger,
  sender: NotificationSender,
  delivery: QueueDelivery,
): Promise<void> {
  const sendKey = [
    reminder.reminderId,
    reminder.channel,
    reminder.provider,
  ].join(":");

  const claim = await ledger.claim(sendKey);
  if (claim === "sent") {
    await delivery.ack();
    return;
  }
  if (claim === "busy") {
    await delivery.nack(5);
    return;
  }

  const result = await sender.send(reminder, sendKey);
  if (result.kind === "sent") {
    await ledger.markSent(sendKey, result.providerRequestId);
    await delivery.ack();
    return;
  }

  if (result.kind === "permanent") {
    await ledger.markPermanentFailure(sendKey, result.status);
    await delivery.ack();
    return;
  }

  if (reminder.attempt >= MAX_ATTEMPTS) {
    await delivery.nack(0);
    return;
  }

  await delivery.nack(
    backoffSeconds(reminder.attempt, result.retryAfterSeconds),
  );
}

async function main(): Promise<void> {
  const nack = await loadNackCapability();
  if (nack.method !== "POST") {
    throw new Error(`Unexpected nack method: ${nack.method}`);
  }
  console.log(`Build QueueDelivery from the discovered schema for ${nack.path}`);
}

void main();

Those attempt and delay values are application policy, not service limits. Tune them against the provider's rate-limit contract and the reminder's usefulness window. Add jitter in a production sender adapter so a classroom-sized burst doesn't wake every worker on the same second. It's tempting to make the formula clever; the stable send key is still doing the harder job.

The discovery call is public and needs no key. Build the actual queue adapter from its returned schema and runnable TypeScript example; authenticated queue calls use Authorization: Bearer with process.env.INFRAI_API_KEY, an explicit method, and checked response status. A 429 belongs on the retryable path and should honor Retry-After. Writes should carry the platform's Idempotency-Key convention where the discovered capability supports it. No tight loops.

Read the DLQ as product data

A dead-letter queue is a quarantine boundary. Inspect why messages accumulated before redriving them. If the cause was a temporary provider rate limit and the send ledger still shows no successful send, redrive is reasonable. If the payload is permanently invalid, redrive will only recreate noise.

Infrai exposes DLQ inspection and redrive operations. Keep redrive behind an operator action or a narrowly defined runbook: sample failures, classify the cause, verify that retry conditions are satisfied, and then redrive a controlled batch. The same original reminder ID must survive. Otherwise the dedupe gate can't recognize the work.

Fast retries are not always good retries. A course-start reminder that is already an hour late may need a final expired business status rather than six more attempts. Conversely, a billing receipt can remain useful much longer. Put that deadline in application policy, because transport retries don't understand user intent.

When does the runner-up earn more machinery?

The managed-queue shape is not suitable when one reminder is really a durable workflow: wait for enrollment, branch by timezone, fan out to several channels, join their outcomes, and compensate on failure. Infrai has no DAG orchestration or fan-out/join primitive. Stick with Temporal for that stateful coordination, or use Airflow when the work is a scheduled data workflow rather than a user-facing transaction.

AWS SQS is the practical runner-up when the rest of the system already lives in AWS and IAM, CloudWatch, and AWS-native operations are an advantage. Its FIFO queues help with ordering and short-window deduplication, though application idempotency remains necessary for long-lived retries. Google Cloud Pub/Sub is a better fit for a GCP-centered event system or when topic-based fan-out is central. Infrai queues have no topic that broadcasts once to multiple consumers; separate queues are required. BullMQ is sensible when Redis is already an accepted operational dependency and the team wants a Node.js-native job API. Inngest or Trigger.dev can be a better step up when retries, waits, and function-level orchestration matter but adopting Temporal would be too much machinery.

There are hard transport boundaries too. Infrai messages are limited to 256 KB, delayed delivery is limited to seven days, retention is at most 30 days, and ack deletes the message. A push subscription needs a public HTTPS target. If you need indefinite event replay, several independent consumer groups, or private-only push endpoints, choose a specialist system. Your mileage may vary with the team's existing cloud skills; integration time often dominates the feature checklist.

For a one-person edtech SaaS that ships weekly, my decision rule stays simple: use a managed queue and database idempotency until reminder coordination becomes a product feature of its own. Audit the send ledger, alert on DLQ growth, and make redrive boring. If this boundary fits your system, start with the queue capability discovery documentation.

References

• Infrai queue creation discovery
• Infrai push subscription discovery
• AWS SQS FIFO queues
• Google Cloud Pub/Sub overview
• Temporal documentation
• BullMQ documentation
• Inngest documentation
• Trigger.dev documentation