Scheduled Reservation Cleanup: Pick Cron Versus Queue (Queues When Recovery Matters)

When deciding how to pick queue versus cron for scheduled data cleanup, use cron for a simple time-based sweep and a queue when the expiry action must survive a transient failure, be retried, or happen after a deliberate delay. For a customer-support reservation held for a fixed window, I would use a cron trigger for the small, predictable path and queue the actual expiration work when a missed or duplicated action would require operator attention.

That recommendation is about recovery semantics, not about which dashboard looks nicer. A timer wakes something up. A queue gives the work a place to wait.

What exactly are you retaining?

Start with the thing that creates the bill and the operational burden: the expiry work, not the cron expression. One schedule definition can wake a cleanup endpoint repeatedly, but each stale reservation still needs a lookup, a state transition, and an outcome that someone can explain to a support agent. Keeping a small schedule is cheap conceptually; retaining the event until it is acknowledged is the part that changes the design.

For this comparison, the hard ceilings matter. A queue message is limited to 256 KB and can be retained for at most 30 days. Delayed delivery tops out at 7 days. Those numbers define the recovery window you can promise. They also make a useful rule: keep the message small, carry a reservation identifier and an expiry timestamp, and fetch the current record in the worker. Do not turn the message into a historical copy of the entire support case.

That choice has a cost. If the reservation has already been reassigned or manually released, the worker must recognize the newer state and do nothing. If you discard the event after acknowledgement, you do not have Kafka-style replay or multiple consumer groups to reconstruct what happened later. I would keep an application audit record separately when support needs an explanation, and treat the queue as delivery machinery rather than an archive.

That is the boundary.

How should I pick queue versus cron for scheduled data cleanup?

Cron is the better fit for a straightforward periodic cleanup: find reservations whose hold window has elapsed, mark eligible rows expired, and return. It is easy to reason about when reliability is not critical and the database operation is bounded. A cron task is also constrained to a public http_url, and its single execution cannot run longer than 900 seconds. A private worker endpoint or a long sweep therefore needs a public HTTPS-facing handoff or a cron-triggered queue worker; it cannot depend on the scheduler executing private application code.

The uncomfortable case is a timeout after the database has changed but before the caller sees the response. A second cron run may be harmless if the state transition is conditional and idempotent. It is not a recovery strategy by itself. Paused cron schedules do not backfill missed triggers, and trigger timing has second-level jitter, so “run every minute” should not be interpreted as “every reservation expires at exactly the minute.”

Queue work earns its place when the expiration command needs retries, delayed execution, or stronger message delivery. Standard queues are at-least-once, so the consumer must be idempotent: update only an unexpired reservation whose hold deadline has passed, and make a repeated message a no-op. FIFO deduplication lasts only 5 minutes, which is not a substitute for that database-level guard.

The trade-off is deliberate: cron keeps the control path small, while a queue retains each state-changing attempt long enough to retry it. If the support team can tolerate the next sweep correcting a missed expiration, cron is enough. If an agent must know that a particular reservation was processed, delayed, or rejected, the queue is the better boundary.

Which product shape matches the recovery boundary?

The options are similar only at the diagram level. A plain cron implementation is a clock plus an HTTP call. Celery beat is a periodic-task scheduler whose useful reliability comes from the broker and worker arrangement around it. AWS EventBridge Scheduler combines schedules with retry and dead-letter handling, which is a better fit when the schedule itself needs a defined delivery policy. Google Cloud Tasks is shaped around deferred task delivery and task-level retry behavior, so it fits a reservation-expiry command that should be attempted independently rather than as one large sweep.

The table is a design comparison, not a promise that one service absorbs the application semantics.

Those are real differences, but none removes the application contract. EventBridge Scheduler does not make a non-idempotent handler safe. Cloud Tasks does not turn a task queue into a queryable event log. Celery beat does not provide a workflow engine merely because it can emit periodic tasks. If the job becomes a DAG, needs fan-out and join, or needs debounce/throttle semantics, these primitives are the wrong abstraction; use a workflow system or build the missing coordination explicitly.

The scheduling surface I would choose for a small REST-based backend is the one that keeps cron and queue operations under one consistent contract, so adding delayed cleanup does not require introducing another integration boundary. That breadth is useful only if the team still chooses the primitive by delivery behavior. It is not a reason to put every recurring task on a queue. For a team that already has a strong broker and workflow platform, using that existing platform is the better choice; a unified REST surface is not a replacement for those features.

A practical reservation-expiry design

Use cron to identify due reservations at a conservative interval. For each eligible record, either perform a conditional expiration directly or publish a compact job containing reservation_id, hold_expires_at, and an idempotency key. The worker re-reads the reservation, checks its current status and deadline, applies one conditional transition, and records a result that support tooling can inspect.

Here is a small discovery check for the unified scheduling surface. It deliberately asks the public discovery endpoint for the current paths instead of hard-coding a request body whose fields may change. Set INFRAI_BASE_URL to the documented /v1 base before running it.

import json
import os
import time
import urllib.error
import urllib.request


def scheduling_paths():
    base_url = os.environ["INFRAI_BASE_URL"].rstrip("/")
    request = urllib.request.Request(
        f"{base_url}/discovery",
        headers={"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}"},
        method="GET",
    )

    for attempt in range(4):
        try:
            with urllib.request.urlopen(request, timeout=10) as response:
                if response.status != 200:
                    raise RuntimeError(f"discovery failed: HTTP {response.status}")
                payload = json.load(response)
                return [
                    item["path"]
                    for item in payload["capabilities"]
                    if item.get("module") == "scheduling"
                ]
        except urllib.error.HTTPError as error:
            if error.code != 429 or attempt == 3:
                raise
            delay = int(error.headers.get("Retry-After", "1"))
            time.sleep(max(delay, 2**attempt))


print("\\n".join(scheduling_paths()))

This is discovery, not a cleanup request. A create or publish call should use the exact schema returned for the selected capability, a client-supplied idempotency key, explicit status handling, and backoff on 429. That restraint matters: an example that invents a cleanup payload teaches a dangerous habit.

Keep the queue payload below the 256 KB limit and set delayed delivery no later than 7 days. Set retention according to the maximum period in which a retry can still be useful, never beyond 30 days. On a standard queue, acknowledge only after the conditional update and its required audit write have succeeded. A failed attempt should be retried with backoff; a permanently invalid record belongs in a dead-letter review path, not in a tight retry loop.

For a long cleanup, cron should enqueue bounded work and let a worker consume it. That split respects the 900-second cron execution limit and makes the work independently retryable. It also gives support a more honest answer than “the nightly job ran”: the system can say which reservation command was attempted, acknowledged, or left for retry.

One small rule prevents a surprising number of incidents: the worker must be safe to run twice.

Decision rule

Pick cron when the job is a bounded periodic sweep, a missed run can be handled by the next sweep, and the endpoint can finish within 900 seconds. Pick a queue when the individual expiry action needs delayed delivery, retry policy, or recovery after a worker-side failure. In either case, make the state transition conditional and observable.

For the customer-support reservation scenario, my default is cron for discovery plus a queue for the expiry command once a failed delivery would leave a customer-facing reservation ambiguous. That is a narrower recommendation than “queues are more reliable.” It tells you where the reliability belongs: around the state-changing action, with retention sized to the support team’s recovery window.

Further reading

• https://en.wikipedia.org/wiki/Cron
• https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html
• https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-delay-queues.html
• https://cloud.google.com/tasks/docs/overview
• https://docs.celeryq.dev/en/stable/userguide/periodic-tasks.html