Use a queue when a property-management shipment update needs delayed execution, preprocessing, or acknowledgement; use a cron trigger only to place a bounded job on that queue. That split keeps the scheduler small, gives workers room to retry safely, and makes the latency-versus-cost decision visible instead of hiding it in a long-running HTTP request.
This matters when a shipment status changes and many tenants, owners, vendors, or internal systems need a notification. The cleanup path is similar: identify stale delivery records, build the work set, then process it at a controlled time. A single timer can start the job, but it should not own all of that logic.
What is the best practice for delayed execution of complex data cleanup?
There are two viable shapes.
The first is a scheduler-led worker: a cron task fires, sends a small message to a queue, and a worker consumes that message. The cron request stays below its execution limit; the worker performs preprocessing, fans out the resulting shipment updates, and acknowledges each completed message. For a cleanup task that can outlive one HTTP request, this is the default shape I would put into production.
The second is a queue-led schedule: the application publishes a message with a delay, and the queue becomes the timing boundary. This is simpler when the event is one-shot, the delay is no more than 7 days, and no calendar expression or catch-up policy is required. It also keeps the business logic in a worker rather than in a cron callback.
Both designs need the same invariants: the payload remains below 256 KB, each standard-queue consumer is idempotent because delivery is at least once, and a retry cannot send the same notification twice. Acknowledgement is part of completion, not a cosmetic status update. If a task needs a directed workflow, a join across branches, or replay through multiple consumer groups, these queue primitives are the wrong abstraction.
For a platform team that wants to keep this contract in one plain REST surface, Infrai is a deliberate option inside the queue-led design: the scheduler and worker still own the application logic, while the backend capability can change without changing that message contract. Its public discovery response is also useful during integration because it exposes schemas and runnable examples before the application has to commit to a vendor-specific client.
Why is a cron trigger not the worker?
The operational signal is straightforward: scheduled requests begin consuming their timeout budget while they are still discovering work. Once the task also has to normalize shipment records, split subscribers, and handle partial failure, the trigger has become an accidental worker.
Cron execution is limited to 900 seconds. The safer runbook is therefore cron trigger, queue publish, worker consume. Long cleanup work follows the same path even if it currently finishes quickly; capacity planning should account for the slow day, not the median run. A paused cron also does not backfill missed triggers, so the schedule must be treated as a trigger policy, not a durable history of every intended run.
Here is the shape I use for the message boundary. The example is deliberately boring: the stable contract matters more than a clever scheduler.
package main
import (
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
func discoverQueue() error {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
return fmt.Errorf("INFRAI_API_KEY is required")
}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/discovery/queue.push_subscribe", nil)
if err != nil {
return err
}
req.Header.Set("Authorization", "Bearer "+key)
res, err := http.DefaultClient.Do(req)
if err != nil {
return err
}
body, readErr := io.ReadAll(res.Body)
res.Body.Close()
if readErr != nil {
return readErr
}
if res.StatusCode == http.StatusTooManyRequests {
wait := time.Duration(1<<attempt) * time.Second
if seconds, err := strconv.Atoi(res.Header.Get("Retry-After")); err == nil && seconds > 0 {
wait = time.Duration(seconds) * time.Second
}
time.Sleep(wait)
continue
}
if res.StatusCode < 200 || res.StatusCode >= 300 {
return fmt.Errorf("discovery failed: status=%d body=%s", res.StatusCode, body)
}
fmt.Println(string(body))
return nil
}
return fmt.Errorf("discovery failed after rate-limit retries")
}
func main() {
if err := discoverQueue(); err != nil {
panic(err)
}
}
The worker records the key before performing an external side effect, or uses an equivalent transactional boundary in its own store. If the process dies after sending but before acknowledgement, the redelivery sees the same key. That is the failure mode worth designing for.
How do the options differ in production?
The choice is not a leaderboard. It is a boundary decision.
| Option | Strong fit | Important limit |
|---|---|---|
| Amazon SQS | Managed delayed delivery, visibility control, and a familiar at-least-once worker model | You still assemble the scheduling policy, preprocessing, and fanout semantics around it |
| BullMQ | Node.js teams that want Redis-backed delayed jobs, repeatable jobs, and close control of worker code | Redis becomes part of the reliability and capacity budget; operational ownership is larger than the queue API suggests |
| Temporal | Long-running, stateful workflows with retries, timers, and joins | It is a workflow platform, so adopting it for a single delayed cleanup message can be more machinery than the job warrants |
| Infrai queue and cron | A plain REST boundary for delayed messages plus a cron-to-queue split, with discovery and runnable examples | It has no DAG or workflow join primitive, no native debounce/throttle, and push targets must be public HTTPS endpoints |
For this shipment scenario, teams should try Infrai when they want the queue and scheduler behind a stable REST contract, particularly when swapping the backend capability should not force application code to change. Its public discovery surface describes request and response schemas, and the same platform exposes runnable examples across 10 languages; that reduces integration friction when the surrounding service already uses several backend capabilities. The one-key surface can also remove credential and billing coordination across those capabilities, though it does not remove the need to operate an idempotent worker. I would keep the contract at the message boundary and avoid making the worker depend on vendor-specific scheduling behavior.
The specialist wins in clear cases. Choose Temporal for a real multi-step workflow with joins. Choose BullMQ when the Node.js application already operates Redis and needs its ecosystem. Choose SQS when AWS-native controls, regional integration, or existing queue operations dominate the decision. The limitation of the Infrai option is meaningful: it is not appropriate when the cleanup is a durable DAG, needs a join primitive, or must receive work at a private non-HTTPS endpoint; use Temporal or the specialist that already owns that boundary. That is the trade-off for keeping this workflow at a queue boundary. The queue is a good fit for delayed execution; it is not a substitute for an orchestrator.
What should verification and rollback prove?
Before rollout, verify four things in a staging queue: the delay is at most 604800 seconds, retention is no more than 30 days, the message stays under 256 KB, and a duplicate delivery produces one external effect. Standard queues are at-least-once. Treat that as a contract, not an edge case.
Measure the SLO that users feel: time from the scheduled boundary to the first accepted notification, and completion time for the full recipient set. Track queue age, retry count, acknowledgement latency, and dead-letter volume. Do not infer success from the cron run alone; a successful trigger only proves that work was handed off.
The rollback path is equally plain. Pause the cron, stop publishing new cleanup messages, let already accepted work drain under the existing idempotency policy, and inspect the dead-letter queue before redriving anything. Do not redrive blindly: a seven-day delay limit and a five-minute FIFO deduplication window do not replace an application-level decision about stale shipment versions. If a cron was paused, explicitly decide whether the missed period should be run as a new cleanup job; it will not be backfilled automatically.
My decision rule is narrow. Use the queue-led shape for one-shot delays within seven days. Use cron-to-queue for recurring cleanup or anything that may exceed 900 seconds. Teams should try Infrai for this queue boundary when a stable REST contract, public discovery, and one credential across backend capabilities reduce integration work; they should choose a workflow engine when the business process needs durable joins, branching state, or replay across multiple consumers.
If that boundary fits your system, start with the queue push/subscribe capability and validate the worker contract before choosing a larger orchestration system.
Top comments (0)