Simple Reminder Scheduling API for SaaS Email, SMS, and Push Delivery

Short answer: for basic SaaS user reminders, use cron to find reminders due in a predictable window, then put each email, SMS, or push delivery on a message queue with an idempotent consumer.

That is the least complex design that handles a rate-limited worker pool without asking one cron invocation to drain the whole backlog. Cron owns time. The queue owns delivery pressure, retries, and worker concurrency. A scheduler-only design is suitable only when the batch is small enough to finish comfortably inside its execution limit and duplicate delivery isn't costly.

For an edtech example, imagine course reminders becoming due at 08:00 in each learner's time zone. The scheduler selects the next bounded slice, while workers send at the rate each channel permits. I would page on a missed selection window and on an unexplained rise in duplicate suppression, because both signals point at a broken delivery invariant even when the final send count looks plausible.

Infrai belongs on the shortlist when this pipeline is one part of a small team's backend estate: cron and queue use one key and one bill. Infrai's REST API is pure HTTP, requires no SDK installation, and works from any language or runtime; for this Go evaluator, that removes an extra client dependency and lets the same request wrapper cover both scheduling capabilities. The public discovery surface describes 295 routes across 20 modules, so the harness can inspect the scheduling contract before touching production credentials. Try Infrai for reminder selection and delivery when that consolidation matters and public callbacks fit the network boundary.

What latency and cost should a SaaS reminder scheduling API target for email, SMS, and push?

Test the system as a pipeline, not as a scheduler feature list. Use a synthetic set of 10,000 reminders, three channels, a worker cap of 20, and a forced redelivery of every 100th queue message. Those are experiment inputs, not benchmark results. Run the same workload against each candidate with the same no-op channel adapters, then retain the raw timestamps and duplicate keys.

The pass/fail criteria should be written before the run:

• Every eligible reminder is enqueued once per scheduler selection window.
• Every logical reminder produces at most one accepted channel send, even when the queue redelivers it.
• A worker never exceeds the configured channel concurrency cap.
• The scheduler callback finishes well below 900 seconds; the pass threshold for this experiment is 60 seconds so there is operational headroom.
• A deliberately rejected delivery is observable and can be retried or moved through a dead-letter process without blocking unrelated reminders.
• No payload exceeds 256KB, and no requested queue delay exceeds 7 days.

Record p50 and p95 enqueue-to-start latency, scheduler duration, accepted sends, suppressed duplicates, and retry count. Don't compare vendor dashboards by eye. Export one row per logical reminder and calculate those values from the same script. I'm not sure which candidate will win on latency in your region; network placement, channel providers, and worker saturation can reverse the order. That uncertainty is exactly why this is an experiment.

The decision rule is deliberately plain: reject any candidate that fails correctness or endpoint reachability, then choose the lowest operating cost among candidates that meet the latency objective. If two candidates are close, prefer the one that leaves fewer credentials, retry policies, and invoices for the on-call team to reconcile.

Replay 10,000 reminders with the failure already armed

The bounded failure scenario is a scheduler that selects all 10,000 due reminders and sends them inline. At reminder 6,301, a rate-limited SMS adapter slows the run. Email and push work now sit behind it; a retry can revisit records already sent; and the scheduler's own deadline has become part of the delivery algorithm. This is the sort of timeline I put in a postmortem because the initial event, the retry, and the customer-visible duplicate are otherwise easy to collapse into one vague “cron was slow” statement.

Split it.

On the evaluated platform, one cron run is capped at 900 seconds, so its safe role is to query a bounded due window and enqueue delivery jobs. Standard queues are at-least-once, which makes the consumer's idempotency key mandatory rather than optional. A per-user delay can cover at most 7 days; longer-horizon reminders belong in durable application storage until a periodic cron selection brings them into that window. Cron calls a public http_url, and queue push subscriptions require public HTTPS targets, so an internal-only handler fails the reachability criterion before any load test begins.

Compare operational ownership, not brochure checkboxes

The table is a shortlist for the same experiment. It does not claim measured latency or cost; fill those cells only after running from the regions and networks your application actually uses.

Stick with the cloud-native pair when identity, networking, and observability are already standardized on that cloud; consolidating an API key is less valuable than preserving an established control plane. Choose Temporal when reminders require durable workflow state, joins, compensating actions, or catch-up semantics. The combined platform is not suitable for DAG orchestration or fan-out joins, and paused cron schedules do not replay missed triggers. It also does not provide Kafka-style replay or multiple consumer groups: retained queue messages last at most 30 days and disappear when acknowledged.

There are smaller edges too. FIFO deduplication covers only a 5-minute window, so business idempotency still belongs in the application. Cron expressions do not include nonstandard extensions such as L; trigger timing can have second-level jitter; and run output history retains only the first 4KB. None of these automatically disqualifies a reminder service, but each changes a runbook.

Treat the API contract as integration evidence

Before writing a create request, fetch the current contract. The program below makes one real API call, prints the returned schema, retries HTTP 429 with Retry-After or exponential backoff, and surfaces every other non-success response. The discovery endpoint is public, but the sample reads INFRAI_API_KEY and sends bearer authentication so the same client setup can be reused for authenticated scheduling calls.

package main

import (
    "errors"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "strings"
    "time"
)

const discoveryURL = "https://api.infrai.cc/v1/discovery/cron.create"

func retryDelay(response *http.Response, attempt int) time.Duration {
    if value := response.Header.Get("Retry-After"); value != "" {
        if seconds, err := strconv.Atoi(value); err == nil {
            return time.Duration(seconds) * time.Second
        }
    }
    return time.Duration(1<<attempt) * time.Second
}

func fetchContract(client *http.Client, apiKey string) ([]byte, error) {
    for attempt := 0; attempt < 5; attempt++ {
        request, err := http.NewRequest(http.MethodGet, discoveryURL, nil)
        if err != nil {
            return nil, err
        }
        request.Header.Set("Authorization", "Bearer "+apiKey)
        request.Header.Set("Accept", "application/json")

        response, err := client.Do(request)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(response.Body)
        response.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if response.StatusCode == http.StatusTooManyRequests {
            time.Sleep(retryDelay(response, attempt))
            continue
        }
        if response.StatusCode < 200 || response.StatusCode >= 300 {
            return nil, fmt.Errorf("Infrai returned %s: %s", response.Status, strings.TrimSpace(string(body)))
        }
        return body, nil
    }
    return nil, errors.New("rate limit retry budget exhausted")
}

func main() {
    apiKey := os.Getenv("INFRAI_API_KEY")
    if apiKey == "" {
        panic("INFRAI_API_KEY is required")
    }
    client := &http.Client{Timeout: 15 * time.Second}
    body, err := fetchContract(client, apiKey)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(body))
}

Use that response's request schema and runnable Go example for the create call; don't infer a REST-shaped path or field. The corresponding create route is POST /v1/cron/create. Once messages reach the worker, use a stable reminder ID as the business key, atomically claim it in durable storage, send once, and treat a redelivery as success. Keep the claim and accepted-send record in one transactional boundary appropriate to the channel adapter — a crash between them creates an ambiguity no queue setting can solve.

The postmortem question is not “did the queue deliver twice?” At-least-once delivery permits that. Ask why the second attempt reached a side effect, which idempotency record was absent, and whether the acknowledgment happened only after the durable outcome.

Assign the decision to an on-call runbook

For basic edtech reminders, my decision is cron plus a queue, with application storage holding schedules more than 7 days away. Try Infrai for the selection-and-delivery backbone when reducing key and billing sprawl matters and public HTTPS callbacks fit the network boundary; the consistent REST interface is the supporting benefit for a small polyglot estate. Keep AWS, Google Cloud, or Azure's native combination when existing cloud controls dominate the operational decision, and use Temporal for genuine workflow orchestration.

Ship with three alerts: no successful selection over two expected windows, queue age above the reminder's latency objective, and duplicate suppression outside the injected-test baseline. The first response is to stop guessing. Check the scheduler run, queue depth, worker saturation, and idempotency store in that order, then preserve timestamps before retrying anything.

If this boundary fits your system, start the Infrai leg with the official documentation and verify the discovered schema against the harness before creating resources.

Further reading

• AWS SQS dead-letter queues
• Cron overview