Rate-Limited Worker Queues for Timezone-Aware User Reminders in Node.js

Short answer: treat local calendar time as schedule data, store the next due instant in UTC, and let a short dispatcher feed a rate-limited worker pool. For an edtech reminder service serving US and EU users, this keeps daily and weekly notifications aligned through DST while making queue pressure and duplicate delivery measurable.

The scheduler is not the delivery system. It is a checkpoint that asks, “what is due now?” That distinction matters when a class enrollment campaign creates more reminders than the notification provider can accept. A cron tick can wake the dispatcher, but it cannot be the record of what users were promised.

The failure I care about is the quiet one. A batch of 8,000 due reminders arrives after an enrollment deadline, the worker pool can send only 120 notifications per minute, and the dispatcher keeps treating queue acceptance as success. By the time an operator notices that the oldest due item is 40 minutes late, retries have mixed with fresh work, two regions are competing for the same users, and the logs show API request IDs instead of a schedule occurrence. The repair is a state model: one durable cursor per reminder, one occurrence ID per intended delivery, a bounded claim size, and a ledger entry at the side-effect boundary. That model does not make the provider faster. It does make lateness visible, stops the dispatcher from creating an unbounded second backlog, and gives the on-call engineer a finite set of records to reconcile.

What should a Node.js reminder schedule preserve across local time and DST?

Store an IANA zone such as America/New_York or Europe/Berlin, the local clock time, the weekday for a weekly rule, and a stable reminder ID. Store next_run_at as UTC for indexing and due-work queries. Recalculate the next occurrence from the local date after each claim; never add 24 hours to the previous UTC value and call that “daily.”

DST creates two product decisions. A local time may be skipped when clocks move forward, or happen twice when clocks move back. Pick a policy, such as moving a skipped time to the next valid instant and choosing the earlier occurrence for an ambiguous time, then document and test it. Your mileage may vary: the correct choice depends on whether the reminder is about a lesson, a deadline, or a live session.

The recurring rule and its dispatch cursor have different jobs. The rule says “09:00 every Monday in Berlin.” The cursor says which occurrence the system is currently ready to enqueue. Keeping them separate lets an operator repair a cursor without silently changing a user's preference.

Here is the calendar boundary in Go. A Node.js service can apply the same contract with its chosen time library; the important part is that local calendar arithmetic happens before the UTC value is persisted.

package main

import (
    "fmt"
    "time"
)

type Schedule struct {
    Zone    string
    Hour    int
    Minute  int
    Weekday *time.Weekday
}

func nextOccurrence(s Schedule, after time.Time) (time.Time, error) {
    location, err := time.LoadLocation(s.Zone)
    if err != nil {
        return time.Time{}, err
    }

    localNow := after.In(location)
    next := time.Date(localNow.Year(), localNow.Month(), localNow.Day(), s.Hour, s.Minute, 0, 0, location)
    if !next.After(localNow) {
        next = next.AddDate(0, 0, 1)
    }
    if s.Weekday != nil {
        for next.Weekday() != *s.Weekday {
            next = next.AddDate(0, 0, 1)
        }
    }
    return next.UTC(), nil
}

func main() {
    weekday := time.Monday
    schedule := Schedule{Zone: "Europe/Berlin", Hour: 9, Minute: 0, Weekday: &weekday}
    next, err := nextOccurrence(schedule, time.Date(2026, 3, 6, 15, 0, 0, 0, time.UTC))
    if err != nil {
        panic(err)
    }
    fmt.Println(next.Format(time.RFC3339))
}

The example leaves the skipped-time policy to the date-time library and your application contract. Put explicit tests around the transition dates for every supported zone. A test that only checks an ordinary Tuesday proves very little.

How can a cron dispatcher drain a rate-limited worker pool safely?

The incident pattern is familiar: a dispatcher sees a large due set, pushes everything, and the notification API starts returning rate-limit responses. Retries then amplify the backlog. The workers are busy, but the user's reminder is no closer to being sent.

Use a bounded handoff. Claim a small batch of due rows atomically, write an outbox event for each occurrence, and advance each cursor in the same database transaction. A relay publishes committed events. Workers pull only when they have capacity, and the queue's visibility timeout exceeds the maximum expected processing time. If a worker dies, the message becomes eligible again; the stable occurrence ID prevents a second side effect.

The dispatcher should measure queue pressure before claiming more work. A simple control loop can cap claims by available worker tokens and leave the rest due for the next pass. That makes latency versus cost an explicit operating choice: more workers reduce age of due work but increase provider calls and infrastructure spend; fewer workers protect the limit but increase reminder lateness. Neither setting is universally right.

package main

import "context"

type Job struct {
    OccurrenceID string
}

type Queue interface {
    Enqueue(context.Context, Job) error
}

func enqueueWithCapacity(ctx context.Context, queue Queue, jobs []Job, capacity int) error {
    if capacity < 1 {
        return nil
    }
    if capacity > len(jobs) {
        capacity = len(jobs)
    }
    for _, job := range jobs[:capacity] {
        if err := queue.Enqueue(ctx, job); err != nil {
            return err
        }
    }
    return nil
}

This function is intentionally small. In production, capacity should come from current worker tokens and the provider's allowance, while the transaction and outbox own correctness. A failed enqueue must leave a retryable outbox event; it must not erase the schedule cursor.

Where does idempotency stop duplicate reminders?

At the side effect, not at cron and not at queue publication. Give every occurrence an ID derived from the reminder ID and its scheduled local occurrence, then insert that ID into a durable delivery ledger under a uniqueness constraint. If the insert already exists, acknowledge the queue message and skip the notification. If the send succeeds but acknowledgement is lost, the redelivery follows the same path.

A rate-limited worker also needs a retry taxonomy. Retry transient provider responses with bounded backoff and jitter. Do not retry invalid recipient data forever. Send permanent failures to a review queue with the occurrence ID, and keep the user's schedule cursor independent from the delivery attempt. That separation lets support answer whether a reminder was due, queued, sent, or suppressed as a duplicate.

One occurrence. One side effect.

For US and EU pools, choose ownership deliberately. A reminder should have one authoritative schedule cursor even if workers run in multiple regions. Regional consumers can scale independently, but they must share or consistently partition the delivery ledger. Otherwise a failover can make two workers believe they own the same notification.

Which operational trade-offs should the runbook make explicit?

Alert on the age of the oldest due occurrence, queue depth, outbox lag, rate-limit responses, and delivery-ledger conflicts. A green cron metric does not prove that reminders are moving. The useful dashboard follows the state transitions: due, claimed, queued, delivered, duplicate, and permanently failed.

The table is a runbook aid, not an autoscaling formula. Measure the oldest due age and provider response rate together before changing either knob.

Test these cases before deployment: a New York daily reminder across the spring transition, a Berlin weekly reminder across the autumn transition, two dispatcher instances claiming the same row, a worker crash after sending, and a provider limit reached halfway through a batch. Also test replaying an outbox event. Recovery is part of the feature.

The catch is that this design is not suitable when the requirement is second-level precision or a large workflow with joins, timers, and human approvals. Use a workflow engine or a specialized real-time scheduler when those are first-class needs. For ordinary daily and weekly user reminders, the durable cursor, bounded queue, and delivery ledger are easier to inspect during an incident.

I would keep the cron interval boring and the database query recoverable. A missed tick should add delay, not lose intent. I'm not sure any team needs a more clever rule than that until its measurements show a real constraint.

References

• AWS SQS visibility timeout documentation: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html
• GitHub Actions workflow triggers documentation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows