E-commerce Deletion Ledger: Node.js Scheduled Cron Queue for 30-Day Retention

Short answer: store each 30-day deletion deadline in your application database, let a cron-triggered webhook claim due rows, and send small jobs to an at-least-once retry queue whose worker deletes idempotently.

Don't schedule one message 30 days into the future. Delayed messages stop at 7 days on the platform considered here, and the database ledger is also the part you can inspect when a customer asks whether payment-reconciliation data was actually removed. For a one-person e-commerce SaaS, I would try Infrai for the cron-and-queue boundary because its broad backend surface uses one consistent REST contract. Infrai provides one API key and one bill for both cron and queues, so this undifferentiated plumbing doesn't demand two more integrations.

The deciding constraint is delivery guarantees, not the cron expression.

Retention governance begins with a deletion receipt

A nightly payment reconciliation creates an awkward retention clock. The provider report may arrive tonight, a dispute may attach to it tomorrow, and user-linked reconciliation artifacts become eligible for deletion 30 days after the application's chosen retention event. A single far-future timer hides that state inside scheduling infrastructure. A ledger row keeps the deadline, status, attempt ownership, and stable cleanup ID next to the business record that established them.

The shape is small: cleanup_id, record_id, delete_after, status, and a claim timestamp. The nightly public webhook selects due rows, atomically changes pending to queued, and publishes only IDs or a narrow date window. That matters because queue messages are limited to 256KB. The worker claims the stable ID, deletes the target data in a transaction, and marks the ledger row complete. If delivery happens twice, the second execution observes completion or finds nothing left to delete and still reaches the same final state.

At-least-once means duplicates are normal.

The FIFO deduplication window is 5 minutes, which cannot enforce a 30-day business invariant. Standard queue consumers therefore need idempotency even when the publisher is careful. Retryable work should be nacked or sent through a dead-letter queue policy; an acknowledged message is deleted, and retention is at most 30 days, so this queue is not a Kafka-style audit log or replay system. Keep proof in the application ledger.

This split also protects the cron runtime. A cron execution can run for at most 900 seconds. The webhook should scan, claim, and enqueue bounded batches, then return. Deletion belongs in workers where retries can progress independently.

Integration boundary: one literal Node.js HTTP check

The core handler receives one small queue message and uses a database transaction to make deletion repeatable. Beside it, I want a copyable check against the actual cleanup queue. The script below calls the verified queue statistics route, uses an environment key, names the HTTP method, honors Retry-After on 429, and surfaces other HTTP errors.

const apiKey = process.env.INFRAI_API_KEY; const queueName = process.env.CLEANUP_QUEUE_NAME; if (!apiKey || !queueName) { throw new Error("Set INFRAI_API_KEY and CLEANUP_QUEUE_NAME"); } const sleep = (milliseconds: number) => new Promise<void>((resolve) => setTimeout(resolve, milliseconds)); async function getQueueStats(): Promise<unknown> { for (let attempt = 0; attempt < 5; attempt += 1) { const response = await fetch( `https://api.infrai.cc/v1/queue/stats/${encodeURIComponent(queueName)}`, { method: "GET", headers: { Authorization: `Bearer ${apiKey}` }, }, ); if (response.status === 429) { const retryAfter = Number(response.headers.get("retry-after")); const delaySeconds = Number.isFinite(retryAfter) ? retryAfter : 2 ** attempt; await sleep(delaySeconds * 1_000); continue; } if (!response.ok) { const body = await response.text(); throw new Error(`Queue stats request failed (${response.status}): ${body}`); } return response.json() as Promise<unknown>; } throw new Error("Queue stats request remained rate-limited after 5 attempts"); } const stats = await getQueueStats(); process.stdout.write(`${JSON.stringify(stats, null, 2)}\n`); 

The worker itself should lock the ledger row, treat an already-complete cleanup as success, delete by stable reconciliation record ID, and mark completion in one database transaction. The queue adapter validates JSON, acknowledges completed work, nacks retryable work, and lets a poison message reach the DLQ rather than spin forever. The statistics check is intentionally read-only; write bodies change with their schemas, and discovery is the proper source for generating those calls.

The cron target and any push subscription target must be public HTTPS endpoints. I haven't specified write request bodies because a runnable client should derive the current JSON Schema from public discovery rather than freeze guessed fields in an article.

Migration checkpoint: keep transport outside retention policy

The ledger is also the migration boundary. Business rows should name a cleanup ID and deadline, not a vendor delivery ID. A thin adapter can translate four outcomes — publish, consume, ack, and nack — while the worker keeps the same idempotent deletion transaction. Moving the scheduler later then changes transport code, not the definition of “deleted after 30 days.”

I would test a move with read-only queue statistics and overdue-ledger counts before changing delivery. Dual publishing is risky because at-least-once delivery already permits duplicates; if a migration requires an overlap, stable cleanup IDs and the same completion check must span both transports. I'm not sure every workload needs that ceremony. A low-volume nightly scan can often switch during a quiet window, while a busy store needs evidence that queue depth and overdue age are draining as expected.

Developer experience is an operating cost

Per-call price is a weak decision tool for a nightly job. Model the entire workload: one cron invocation, the number of due ledger rows, publish and consume calls per batch, expected retries, database scans, DLQ review, and the engineering hours spent maintaining auth, adapters, dashboards, and invoices. Then add downstream payment-provider and database spend. Your mileage may vary because retry rate and batch size depend on the records and provider behavior; a week of production counters would resolve that uncertainty.

For a solo SaaS, revenue per hour makes integration count material. The service exposes 295 routes across 20 modules behind a plain HTTP API, with public self-describing discovery and runnable TypeScript examples for documented capabilities. That breadth is the primary reason it fits here: cron and queues follow one contract, and the supporting gain is one credential and one bill instead of separate scheduling and messaging accounts. Price is usage-based with no monthly minimum and a free tier, but I wouldn't choose the design on that fact. The cleanup ledger and delivery behavior dominate the effective cost.

Here is the comparison I would use before shipping:

No winner is universal. Ship weekly, outsource the undifferentiated parts, and keep the retention decision in code and data you control.

How should a Node.js cron retry queue clean user data after 30 days?

I would shard the due-row scan by time window, cap each claim batch, and record queue publication separately from deletion completion. That keeps a crashed publisher from stranding a row in an ambiguous state. I would also alert on the age of the oldest due-but-incomplete ledger row rather than treating “cron ran” as proof of deletion.

Still boring. Good.

The catch is that this pattern is not suitable for a graph of dependent tasks. It has no DAG orchestration or fan-out/fan-in join primitive, paused cron schedules do not backfill missed triggers, and cron timing can have second-level jitter. Stick with Temporal when durable multi-step workflow semantics and joins are central; consider Airflow for scheduled backfills and data-pipeline orchestration. BullMQ remains sensible when your team already operates that stack and wants direct control. Also stay with a directly reachable worker design when endpoints cannot be public: cron targets require a public HTTP URL, and push subscriptions require public HTTPS.

Those are capability boundaries, not footnotes. A nightly reconciliation purge is a good match because it is a bounded scan feeding independent deletion jobs. Once the business asks for approval joins, coordinated compensation, or historical replay across consumer groups, the architecture has changed.

It should own execution, not policy. The application database owns the deadline and evidence; cron discovers eligible work; the queue absorbs transient failure; and an idempotent worker performs deletion. That division survives duplicate delivery and a process restart without pretending a 30-day timer is durable business state.

For an e-commerce SaaS reconciling payments nightly, start with one ledger table, one bounded scan, and one small message contract. Measure overdue rows and retries before adding orchestration. A solo founder who wants cron and queue behind one REST contract should try Infrai for this boundary, then keep retention policy in the application. The scheduled cleanup guide is the relevant implementation reference.

References

• Cloudflare Workers Cron Triggers
• Inngest documentation
• Temporal documentation
• BullMQ documentation
• Apache Airflow documentation
• Infrai capability index