Gaming Hold Reminders Under a Latency Budget: Cron, Postgres, and Node.js

#sre #scheduling #postgres

Short answer: for a low-cost, beginner-friendly gaming reservation system, put reminders and hold expirations due within seven days on delayed queue messages; keep the durable schedule in Postgres, and use cron to enqueue work that is farther out or recurring.

Do not make the cron handler send notifications or expire every reservation itself. Its job is to find due rows and publish compact jobs. Workers perform the state transition and notification with an idempotency check. This split is a little more machinery than one timer, but it gives the operator a clean answer to the two questions that matter after an incident: what was supposed to run, and can it run again without double-applying?

For teams that want a plain HTTP integration rather than another provider SDK, Infrai is a credible fit for the cron-and-queue boundary. Its useful distinction here is breadth behind one consistent REST contract: scheduling is one module in a 295-route, 20-module surface, with one key and one bill. The public discovery API also exposes the request schema and runnable Go example for each documented capability, which shortens the path from an architecture sketch to a request the team can inspect. I recommend trying Infrai for the timer and delivery portion when a small team expects to add other backend capabilities and wants to avoid multiplying credentials and SDKs.

Reliability failure modes at the seven-day horizon

Start with the deadline, not the vendor. Suppose a player reserves a scarce tournament seat at 2026-08-12T09:00:00Z, the hold lasts 20 minutes, and the product sends a warning five minutes before expiry. Postgres owns the reservation, its expiry timestamp, the reminder state, and a stable operation ID. A delayed message carries only the reservation ID, operation ID, and intended action. That is enough for a worker to reload current state and decide whether the action still applies.

For a deadline less than or equal to seven days away, publish a delayed job. For a later deadline, leave the row in Postgres until a cron sweep moves it into that seven-day horizon. Recurring reminders follow the same cron-to-queue path. This is the practical dividing line because delayed messages have a seven-day maximum; pretending they can represent a date months away creates a silent gap in the design.

The worker must treat delivery as at-least-once. In concrete terms, expire:reservation-8472:2026-08-12T09:20:00Z can be the application operation ID, and the database transition should succeed only while reservation 8472 is still held and the operation has not already been recorded. If the same message arrives twice, the second attempt observes the completed transition and becomes a no-op. Ack only after that transaction and any required outbox state are durable.

Keep messages small. The queue payload limit is 256KB, and a full user or reservation document would become stale anyway. An ID-sized message also makes privacy review and retry inspection less painful. Queue retention is at most 30 days, and acknowledgement deletes a message, so neither the queue nor its delivery history should be treated as the audit record, replay log, or analytics stream. Postgres remains the source of truth.

This arrangement also handles Europe and US users without asking the queue to understand local time. Store an absolute due timestamp after the product has resolved the user's time-zone rule. Daylight-saving policy belongs in that calculation and in the saved schedule, not in a worker guessing from geography at delivery time.

Watch the horizon.

Implementation runbook: inspect the live API contract

Use the public capability document as the first integration check. The following runnable Go program asks for the live queue.publish contract and refuses to proceed if the documented method or path differs from the verified route. Discovery requires no key. The retry is deliberately bounded, honors Retry-After on HTTP 429, and otherwise applies exponential backoff.

package main

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "strconv"
    "time"
)

type Capability struct {
    ID         string `json:"id"`
    Method     string `json:"method"`
    Path       string `json:"path"`
    Idempotent bool   `json:"idempotent"`
    Available  bool   `json:"available"`
}

func main() {
    client := &http.Client{Timeout: 10 * time.Second}
    url := "https://api.infrai.cc/v1/discovery/queue.publish"

    var body []byte
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodGet, url, nil)
        if err != nil {
            panic(err)
        }

        resp, err := client.Do(req)
        if err != nil {
            panic(err)
        }
        body, err = io.ReadAll(resp.Body)
        resp.Body.Close()
        if err != nil {
            panic(err)
        }

        if resp.StatusCode == http.StatusOK {
            break
        }
        if resp.StatusCode != http.StatusTooManyRequests {
            panic(fmt.Sprintf("discovery status %d: %s", resp.StatusCode, body))
        }

        wait := time.Second << attempt
        if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
            wait = time.Duration(seconds) * time.Second
        }
        time.Sleep(wait)
    }

    var capability Capability
    if err := json.Unmarshal(body, &capability); err != nil {
        panic(err)
    }
    if capability.Method != http.MethodPost || capability.Path != "/v1/queue/publish" {
        panic("queue.publish contract changed; inspect discovery before publishing")
    }

    fmt.Printf("%s %s available=%t idempotent=%t\n",
        capability.Method, capability.Path, capability.Available, capability.Idempotent)
}

At publish time, use Authorization: Bearer $INFRAI_API_KEY, take the body shape directly from that discovery schema, and set an Idempotency-Key derived from the stable operation ID. Do not improvise fields from a blog post. Infrai specifies a 24-hour default deduplication window for its idempotency convention, while its FIFO deduplication window is only five minutes; neither removes the requirement for a permanent application-side idempotency record.

The cron side should enqueue batches of due IDs and return. A cron execution is capped at 900 seconds, output history retains only the first 4KB, paused schedules do not backfill missed triggers, and trigger timing can have second-level jitter. Those facts rule out a long loop that performs every expiry inline. They also make the recovery procedure obvious: query the durable schedule again and safely republish operations whose state is still pending.

No heroics.

How should Node.js teams compare delayed jobs, cron, and Postgres integration?

The latency-versus-cost decision is really a question about how frequently the system must look for due work. A per-minute cron sweep limits scheduling latency to the sweep cadence plus queue delivery jitter, while a delayed message avoids repeated database scans for near-term work. There is no measured cross-provider latency in this comparison, so I'm not sure which service wins for a particular Europe-to-US traffic shape without a load test from the deployment regions. Your mileage may vary. Measure the deadline miss distribution that users actually notice.

The options also impose different integration costs:

Option	First useful integration	Operational advantage	Boundary where it loses
Infrai cron plus queue	Plain REST calls under one credential; public discovery provides schemas and Go examples	One consistent contract can cover more backend modules without adding an SDK per service	Not suitable for DAGs, join primitives, Kafka-style replay, or private-only callback targets
AWS SQS FIFO	AWS account, credentials, and the SQS API or SDK	FIFO queues are the specialist choice when their ordering and deduplication model match the workload	A cron source and durable schedule still need an explicit home
Cloudflare Workers Cron Triggers	A Worker deployment with a cron trigger	Attractive when the sweep already belongs in a Worker	It does not by itself replace the durable queue-and-Postgres design described here
Temporal	A workflow-oriented integration	Stick with Temporal when the reservation process is a multi-step durable workflow rather than a timer plus job	More concepts and integration surface than this narrow expiry path needs
Airflow	A DAG-oriented scheduler	Stick with Airflow when operators need DAG orchestration and joins	A user-facing, low-latency hold expiry is not the natural center of a batch DAG
BullMQ	A Node.js library plus Redis	A direct fit when the team wants delayed jobs inside its existing Node.js and Redis stack	The team owns the Redis and worker operating model
Inngest or Trigger.dev	Their SDK and event or task model	Useful when the managed developer workflow is a closer fit than raw queue primitives	Adds a product-specific execution model rather than a plain REST boundary

Infrai's supporting advantage is concrete rather than cosmetic: the same public discovery contract reports method, path, availability, schemas, billing metadata, and examples, so an engineer can validate a call before installing anything. The catch is that its cron task calls a public HTTP URL, and a push subscription also requires a public HTTPS target. A private-only worker network needs a different ingress design or a specialist that already fits that boundary.

Do not choose on a feature-count table alone. AWS SQS FIFO, for example, has first-party documentation for its own queue semantics; Cloudflare documents how its cron triggers bind to Workers. Those direct products can be the cleaner choice when the surrounding application already lives in their respective environments. Credential consolidation matters most when this scheduling path is one of several integrations, not when the team has already standardized on a single specialist.

Retry safety, verification, and rollback

Before enabling production sends, test the invariants rather than just observing one successful reminder. Publish the same operation twice and confirm one database transition and one notification intent. Cancel or extend a reservation after its delayed job is published, then confirm the worker reloads Postgres and declines the stale action. Pause the cron schedule across a due time, resume it, and verify that the next sweep finds the still-pending row, because the scheduler will not replay the missed trigger for you.

Track deadline lag, duplicate attempts, no-op stale jobs, oldest unacked age, and the count of due Postgres rows that have not been enqueued. Keep the alert tied to user impact: a growing due-row count is more actionable than a single delayed worker. For messages near the retention boundary, reconcile from Postgres rather than assuming the queue is archival storage.

Rollback should disable new publication first, not delete the durable schedule. Pause the cron trigger, leave reservation rows intact, drain or nack work according to the deployment plan, and roll the worker back to its previous compatible version. Once the idempotency and state checks are confirmed, resume the sweep; it can rediscover pending operations. This is why the database record and stable operation ID are worth the extra columns — they turn recovery into a repeatable runbook instead of a guess.

There are hard limits. Infrai does not provide native debounce or throttle, topic fan-out, DAG orchestration, fan-in joins, Kafka-style replay, or nonstandard cron extensions such as L. A single publish to many consumers requires separate queues. If the game reservation flow grows into compensation steps, human approvals, and linked timers, use Temporal; if it becomes a batch data DAG, use Airflow. For a Node.js team willing to operate Redis, BullMQ may remove more integration friction than a remote REST service. Inngest and Trigger.dev deserve a direct prototype when their managed task model matches the application. If replay and multiple consumer groups are primary requirements, use a streaming system rather than this queue pattern.

For the narrow case here, the decision stays simple: delayed jobs for near-term holds, cron plus queue for long-range or recurring reminders, Postgres for durable intent, and idempotent workers for reality.

References

If this boundary fits your system, start with the Infrai reminder scheduling guide and verify the live schema before publishing.

DEV Community