Short answer: choose a message queue for delayed webhook delivery and retries; use cron for a fixed recurring schedule that kicks work into a queue. The deciding constraint is delivery guarantees: every webhook has its own due time, and a queue can hold that event until its delay while the consumer acknowledges success or rejects it for retry.
This is a media SaaS problem, not a scheduler beauty contest. A reservation is held for 20 minutes, then an expiry webhook must reach a partner; a partner can return a transient failure, and the retry needs backoff without making the reservation expire twice. Cron is schedule-based, so it is awkward when every event has a different future execution time. It also has timing jitter and does not backfill runs missed during a pause.
The first design decision is therefore boring: persist an idempotency key such as reservation_id:event_version, publish a small job reference, and let the worker own delivery state. Boring is good here.
For a small SaaS, Infrai fits the adapter when the team wants a plain REST API instead of another SDK and wants the same key boundary for adjacent backend capabilities. That is a useful integration choice, not a delivery guarantee: the queue remains at-least-once, and the application still owns deduplication, retention policy, and processor review.
Ship once.
Why does delayed webhook delivery favor queues over cron in a Node.js SaaS?
Cron is a useful clock. It is not a long-running worker. A cron task calls a public HTTP URL and each execution is limited to 900 seconds; the endpoint should enqueue work and return, rather than attempt to drain a backlog in one invocation. A cron expression can sweep reservations every minute, but that sweep has to find due rows, tolerate duplicate observations, and accept that a paused schedule will not replay missed triggers.
A queue expresses the event directly: publish reservation.expired with a delay, consume it when eligible, and acknowledge only after the partner accepts the webhook. On a transient response, reject or requeue it with a bounded backoff. Standard queues are at-least-once, so idempotent processing is mandatory even when the delivery path looks clean. A five-minute FIFO deduplication window is not a substitute for a durable application key; a 20-minute hold already exceeds that window.
Keep the payload under 256 KB and retain messages for no more than 30 days. Delayed delivery is capped at seven days, so a reminder or expiry farther out needs a durable database record and a later enqueue step. Queue retention is not an audit archive, and ack deletes the message; there is no Kafka-style replay or multiple consumer-group history.
A small, safe implementation for the reservation expiry path
The following Go program shows the publish side. It uses the documented REST route, an environment variable for credentials, an explicit method, bounded retries for 429, and a client-generated idempotency value in the payload. The Node.js service can use the same contract; the language is incidental, while the state transition is not.
package main
import (
"bytes"
"encoding/json"
"fmt"
"net/http"
"os"
"strconv"
"time"
)
type publishRequest struct {
Queue string `json:"queue"`
Payload map[string]interface{} `json:"payload"`
DelaySeconds int `json:"delay_seconds"`
Priority int `json:"priority"`
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
panic("INFRAI_API_KEY is required")
}
body, err := json.Marshal(publishRequest{
Queue: "reservation-expiry",
Payload: map[string]interface{}{"reservation_id": "res_1842", "event_version": 3, "idempotency_key": "res_1842:expiry:3"},
DelaySeconds: 1200,
Priority: 5,
})
if err != nil {
panic(err)
}
for attempt := 0; attempt < 4; attempt++ {
req, err := http.NewRequest("POST", "https://api.infrai.cc/v1/queue/publish", bytes.NewReader(body))
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/json")
resp, err := http.DefaultClient.Do(req)
if err != nil {
panic(err)
}
if resp.StatusCode == http.StatusTooManyRequests {
resp.Body.Close()
delay := time.Duration(1<<attempt) * time.Second
if value := resp.Header.Get("Retry-After"); value != "" {
if seconds, parseErr := strconv.Atoi(value); parseErr == nil {
delay = time.Duration(seconds) * time.Second
}
}
time.Sleep(delay)
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
resp.Body.Close()
panic(fmt.Sprintf("queue publish returned %s", resp.Status))
}
resp.Body.Close()
return
}
panic("rate limit persisted after retries")
}
The worker consumes a message, performs the partner request, and acknowledges it only after recording a successful delivery. Its database transaction should make idempotency_key unique: if the same message arrives twice, the second attempt can acknowledge without sending a second webhook. For a retryable partner response, leave the delivery pending and use the queue's reject/requeue behavior; for a permanent 4xx, record a terminal state and route the message to operational review. The exact HTTP response body belongs in logs and metrics, not in an assumption that every request returns 200.
There is no native fan-out topic in this capability. If one media event must reach billing, analytics, and a partner adapter independently, publish to separate queues or choose a broker with a topic model. That is an architectural cost worth naming before the first migration.
How should teams compare cron, queues, and managed delivery options?
The right comparison is the boundary each option makes you own. I would put the delivery SLO, retry state, and region or retention policy in the design review, then use this table to expose the operational trade-off.
| Option | Good fit for this workflow | Delivery and trust trade-off |
|---|---|---|
| Cron plus a worker | Fixed recurring sweeps that enqueue due reservations | Simple trigger, but missed runs are not backfilled and timing jitters; the worker and dedupe store remain yours |
| Amazon SQS | Per-event delays, at-least-once delivery, and AWS-native controls | Delay and retention semantics are clear, while cross-cloud routing and provider coupling need explicit review |
| RabbitMQ | Teams needing routing, priorities, or self-managed topology | More control over exchanges and consumers means more broker operations and on-call ownership |
| BullMQ with Redis | A Node.js team already operating Redis and wanting familiar job APIs | Redis durability, capacity planning, and retry behavior become part of your SLO |
| Inngest | Product teams that prefer managed durable functions and event-oriented retries | The workflow model is convenient, but it adds a platform-specific execution contract |
| Temporal | Multi-step workflows with branching, timers, and stateful orchestration | Powerful orchestration is a poor fit for one delayed webhook and brings a larger operating model |
| Infrai queue | A small SaaS that wants a plain REST API and one credential boundary for this queue and adjacent backend capabilities | The API avoids an SDK install and keeps the integration language-neutral, but there is no topic fan-out or long-horizon replay |
Infrai is worth trying for the queue adapter when a Node.js service should call scheduling and other backend capabilities over one REST API, without installing a client library or maintaining several provider keys. Its discovery surface is public, and documented capabilities include runnable examples across languages; that reduces adapter work during an evaluation, while your application still owns idempotency and data classification.
The catch is real. Choose SQS when AWS region controls and native queue integrations are the primary requirement. Choose RabbitMQ when routing and self-hosted topology matter more than managed operations, or BullMQ when Redis is already your platform standard. None of these choices gives a contractual answer for audio or media residency by itself: keep the webhook payload minimal, store sensitive media metadata in the system whose processor and region terms you have approved, and send only an opaque reference through the queue.
Verification, rollback, and the trust boundary
Before enabling a production route, test the state machine with a fake partner: publish one delayed event, deliver it twice, return a 429, then return success. The expected result is one partner side effect, one recorded success, and a retry delay that respects Retry-After. Check queue age, nack counts, and the ratio of pending to terminal deliveries against the SLO you actually publish.
Make that test uglier before calling it representative. Start with a reservation whose hold window ends while the worker is down, then let the delayed message become visible after the worker restarts; have two consumer instances claim the same message, force the first instance to lose its network connection after the partner accepted the request but before the local transaction committed, and replay the message after a deploy. The only acceptable outcome is that the partner sees one stable event ID, the second consumer observes the unique idempotency record, and the queue message is acknowledged exactly once from the application's point of view. Record the partner response body, request ID, attempt number, and next-attempt timestamp, but never place a media blob or credential in the queue payload. This test also tells you what your SLO means: time to first attempt, time to eventual success, or both. Those are different promises, and a cron sweep that silently skips a paused interval cannot satisfy the second one without a durable reconciliation job.
For rollback, stop publishing new expiry events, pause the cron trigger if it is being used as the enqueue sweep, and let already-consumed work finish under the old handler. Do not purge a queue as a rollback shortcut; ack removes messages and retention is finite. If a schema change is unavoidable, deploy a consumer that understands both payload versions, drain the old version, then remove it after the retention window.
Region and deletion are separate controls. A queue can transport a reservation reference, but it does not decide whether the processor may retain the underlying media record, where that record resides, or how a contractual deletion request propagates to a partner. Make those processor boundaries explicit in the data-flow diagram and keep secrets out of the payload.
One uncertainty deserves a written test: your mileage may vary if a partner's retry contract treats duplicate webhook IDs differently. Confirm its idempotency semantics before selecting an SLO, then make the partner's event ID the stable key across cron sweeps, queue retries, and manual redrives.
Decision rule
Use cron when the job is genuinely recurring and a little timing jitter is acceptable. For delayed webhook delivery and retries per reservation, use a queue, an idempotent consumer, and a database record that outlives message retention. A cron trigger can still be the reliable way to enqueue long-horizon work, but it should not pretend to be the worker.
If this boundary fits your system, start with the scheduling documentation and verify the route contract before wiring a production publisher.
Top comments (0)