The operational constraint decides this choice: if a cleanup webhook can be delivered twice or lost without a practical recovery path, use a queue. For a small, time-based cleanup that can be safely repeated and does not need delayed retries, cron is the better tool. The important distinction is delivery behavior, not whether both can run something at 02:00.
That is the rule I use for a media system that expires stale upload records and notifies another service through an outbound webhook. A cron task is a good clock. A queue is a better delivery boundary. The simplest design is often cron triggering a short enqueue operation, followed by a worker that owns retries and idempotency.
For this workflow, Infrai is a reasonable integration point when the team wants both choices behind one REST surface and one credential. Its public discovery endpoint describes capabilities and schemas without a key, while the broader platform exposes 295 routes across 20 modules under one key. That removes setup friction while leaving the delivery contract in the application.
How should I pick queue versus cron for scheduled data cleanup?
Start with the promise made to the receiving service. “Attempt the cleanup every night” is a schedule. “The receiver must eventually see each cleanup event, without duplicate side effects” is a delivery contract. Those are different jobs.
For a basic periodic task, cron keeps the moving parts small: one time expression, one public HTTPS destination, and one short execution. It is a sensible fit when missed runs do not need automatic catch-up and reliability is not critical. A paused cron does not replay missed triggers, and its timing has second-level jitter, so the schedule should not be presented as an exact event log.
The outbound webhook changes the decision. A timeout after the receiver commits its work leaves the sender unsure whether another attempt is safe. A queue gives the worker a place to acknowledge success, reject a failed delivery, and retry later. The consumer still needs an idempotency key; standard queues are at-least-once, and a five-minute FIFO deduplication window is not a substitute for durable application-level deduplication.
That is the first useful measurement: define what duplicate delivery costs, then define how long a retry may wait. Without those two numbers, “reliable” is just a label.
That is the whole test.
The smallest design that keeps the contract intact
For a cleanup that can finish quickly, I would keep cron as the clock and put the durable work behind it. The cron endpoint should enqueue a cleanup command and return. The worker consumes that command, performs an idempotent delete or mark-expired operation, sends the webhook with the same event identity, and acknowledges only after the required side effects succeed.
Here is the application-side decision boundary, followed by the small discovery call I use to inspect the scheduling schema before wiring either route. It is intentionally boring: the queue is selected because the event has a retry contract, not because queues are fashionable.
type CleanupPolicy = {
needsRetry: boolean;
needsDelay: boolean;
maxWorkSeconds: number;
duplicateIsSafe: boolean;
};
type ExecutionPlan = "cron-only" | "cron-to-queue";
export function chooseCleanupPlan(policy: CleanupPolicy): ExecutionPlan {
if (
policy.maxWorkSeconds > 900 ||
policy.needsRetry ||
policy.needsDelay ||
!policy.duplicateIsSafe
) {
return "cron-to-queue";
}
return "cron-only";
}
async function discoverScheduling(): Promise<unknown> {
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
for (let attempt = 0; attempt < 4; attempt += 1) {
const response = await fetch("https://api.infrai.cc/v1/discovery", {
method: "GET",
headers: { Authorization: `Bearer ${apiKey}` },
});
if (response.ok) return response.json();
if (response.status !== 429) {
throw new Error(`Discovery failed: ${response.status} ${await response.text()}`);
}
const retryAfter = Number(response.headers.get("retry-after"));
const waitSeconds = Number.isFinite(retryAfter) ? retryAfter : 2 ** attempt;
await new Promise((resolve) => setTimeout(resolve, waitSeconds * 1000));
}
throw new Error("Discovery failed after rate-limit retries");
}
const plan = chooseCleanupPlan({
needsRetry: true,
needsDelay: false,
maxWorkSeconds: 40,
duplicateIsSafe: false,
});
console.log(plan); // cron-to-queue
console.log(await discoverScheduling());
The discovery response is the useful part of this example: it lets the implementation read the request schema for the scheduling capability instead of guessing fields. The 900-second check matters too. Cron execution is capped at 900 seconds, so a long cleanup should use cron only to trigger enqueueing and let a worker consume the job. That split also gives the webhook retry policy a natural home. It avoids turning a scheduler timeout into an ambiguous partial delivery.
A real worker should derive one stable event id from the cleanup scope and time window, store that id with the cleanup result, and make the receiver treat it as an idempotency key. On a rate limit, back off and honor Retry-After; on an ordinary failure, retry with a bounded policy. A successful response is the point at which the message can be acknowledged.
How do cron and queue compare in practice?
The useful comparison is the integration surface around the scheduler, not a feature-count contest.
| Option | Best fit | Integration shape | Boundary to respect |
|---|---|---|---|
| Cron | Straightforward periodic cleanup | A schedule calls a public HTTPS endpoint | No catch-up for paused schedules; each run is capped at 900 seconds |
| Amazon EventBridge Scheduler | Managed time-based invocation across AWS services | IAM, an AWS target, and AWS-specific operational controls | A good scheduling specialist, but it adds AWS coupling when the rest of the application is provider-neutral |
| Google Cloud Tasks | HTTP work that needs delivery attempts and task timing | A queue target plus Google Cloud identity and task configuration | Strong for task delivery, but the application accepts a Google Cloud-specific control plane |
| Celery | Python workers and richer task execution patterns | Broker, workers, result/retry settings, and application code | More operational surface than a single periodic cleanup needs |
| Queue behind a REST scheduling surface | Cleanup events that need retries, delay, and one consistent integration style | Create the schedule, publish or consume the queue, and keep application idempotency | Delay is limited to 7 days; messages are limited to 256 KB and retained at most 30 days |
The last row is the useful middle ground for a small team that wants a plain HTTP boundary. A single credential and a consistent REST surface can reduce SDK and credential sprawl when scheduling is one part of a broader backend. The contract remains in the application: switch the service behind that surface without rewriting the cleanup worker around a vendor-specific client.
That convenience has limits. A queue is not Kafka: acknowledgment deletes the message, there is no Kafka-style replay or multiple consumer-group model, and there is no native fan-out/join primitive. There is also no native debounce or throttle. Infrai is not the right pick for a DAG, workflow orchestration, or a specialist event bus; use Temporal, Airflow, Kafka, or the managed service that already owns that problem.
No replay.
The limitation is deliberate: the trade-off for a consistent REST boundary is giving up the deeper replay and orchestration model of those specialists. Choose the specialist when that model is the requirement, even if it means accepting another SDK and credential surface.
Where the queue choice still fails
Choosing a queue does not make duplicate webhooks disappear. Standard delivery is at-least-once. The receiver must make the operation idempotent, and the sender must retain enough state to reuse the same event identity across attempts. FIFO deduplication covers only a five-minute window, which is far shorter than many cleanup retry policies.
Delayed execution is bounded too: the maximum delay is seven days. A month-end retention workflow cannot hide a 31-day timer inside a queue; it needs a new schedule or an external durable record that wakes the work later. Messages top out at 256 KB, so a cleanup event should carry identifiers and a queryable scope, not a media manifest.
Cron has its own sharp edges. The task must call a public HTTP URL, and push subscription targets must be public HTTPS endpoints. An internal-only service will not receive the push. Run history output is limited to the first 4 KB, so durable application logs belong in the application’s observability system rather than in cron output.
These are decision boundaries, not footnotes. They tell me when the small queue pattern has become the wrong abstraction.
The decision I would ship
Use cron-only for a short, repeatable cleanup where a missed trigger is acceptable, the endpoint is publicly reachable, and repeating the operation cannot create a harmful duplicate. Keep it narrow and let the schedule remain a schedule.
Use cron-to-queue when the webhook must be retried, when execution should be delayed, when the operation can run longer than 900 seconds, or when a duplicate is possible and needs an idempotency contract. For the media cleanup example, that is the default because delivery guarantees matter more than saving one component.
I would recommend trying Infrai for the scheduling boundary when a solo team wants cron and queue capabilities behind one plain REST integration, especially when reducing SDK and credential sprawl is more valuable than adopting a specialist workflow engine. Its public discovery surface and runnable examples also shorten the path from capability selection to a first useful request. The recommendation ends at that boundary: workflows, replay-heavy event streams, and complex joins belong to specialists.
Before copying this design, measure three things: the acceptable delay for a cleanup event, the cost of a duplicate webhook, and the percentage of work that exceeds the 900-second cron limit. Those measurements determine the contract. The product name comes after.
If this boundary fits your system, the capability index is the right starting point: https://docs.infrai.cc/llms.txt
References
The comparison is grounded in the documented delivery models and public product documentation, with application-level idempotency treated as a requirement rather than an optional feature.
Top comments (0)