Use a delayed queue for daily healthtech report email delivery, with a worker that treats every message as at-least-once and a durable delivery record that makes retries harmless. The deciding constraint is the failure boundary: scheduling the task, sending the email, and recording the result are separate operations, so the design must make their disagreement observable and recoverable.
The queue is a delivery coordinator, not proof of exactly-once email delivery. That distinction matters when a report contains sensitive operational information and a process can fail after an email provider accepts a message but before the application records completion.
The queue is not the ledger.
Transport is not business state.
What does the delivery contract need to guarantee?
This architecture decision record starts with four invariants. A stable delivery ID identifies the report, recipient, and reporting date. Every retry reuses it. The delivery ledger is the application idempotency boundary. A worker acknowledges a message only after the relevant state is committed. Finally, the queue handles bounded delay and asynchronous work; it does not become a workflow engine by implication.
Those rules are more valuable than a particular queue brand. A daily report is a good queue workload because its delay horizon is bounded, its generation and delivery can be separated, and a worker can control concurrency around the email provider. A queue also supplies retry mechanisms for transient send failures, while workers provide fine-grained control over how much asynchronous work is active at once.
The payload should contain a report reference, recipient policy, reporting date, and stable delivery ID rather than the generated report itself. The message body limit is 256 KB. Retention is at most 30 days, and acknowledgement deletes the message; this is not a Kafka-style replay log with multiple consumer groups. A seven-day maximum delay is enough for a daily report schedule, but it is not a calendar service for arbitrary future appointments.
The critical path is deliberately small:
package main
import (
"context"
)
type Delivery struct {
ID string
ReportRef string
Recipient string
ReportDate string
}
type Ledger interface {
AlreadyCompleted(ctx context.Context, id string) (bool, error)
MarkCompleted(ctx context.Context, id string) error
}
type Mailer interface {
Send(ctx context.Context, delivery Delivery) error
}
// Process is safe to invoke more than once for the same queue message.
func Process(ctx context.Context, delivery Delivery, ledger Ledger, mailer Mailer) error {
completed, err := ledger.AlreadyCompleted(ctx, delivery.ID)
if err != nil {
return err
}
if completed {
return nil
}
if err := mailer.Send(ctx, delivery); err != nil {
return err
}
return ledger.MarkCompleted(ctx, delivery.ID)
}
This does not claim exactly-once email delivery. If the provider accepts the email and the process dies before MarkCompleted, a later attempt can still send a duplicate. The stronger boundary requires a provider-supported idempotency key, or a transactional outbox combined with a provider contract that makes the delivery operation repeatable. Without one of those, the application can make its own decision idempotent, but it cannot make two independent systems atomic.
That is the first trade-off. A shorter retry schedule can reduce report delay, but it creates more active work and can amplify provider pressure. A conservative schedule reduces activity while tolerating a later report. The right setting follows the report's operational deadline, not a claim that any queue guarantees a particular latency.
Which message queue service supports delayed email scheduling?
There is no universal winner. Amazon SQS is a sensible queue-first choice for an AWS-centered system. Google Cloud Tasks is a natural comparison when the team wants HTTP-oriented dispatch to a separately operated worker. Azure Service Bus is a broader messaging choice for an Azure estate. Airflow and Temporal belong in the comparison as boundary markers: they are workflow-oriented systems for dependency graphs and long-running orchestration, not merely substitutes for a delayed message.
| Option | Where it fits | Boundary to verify |
|---|---|---|
| Amazon SQS | A queue-based retry path inside an AWS-centered application | Standard delivery is at least once; the worker still needs an idempotent delivery decision and a delay horizon that fits the report schedule |
| Google Cloud Tasks | HTTP dispatch to a worker whose endpoint and retry policy are application concerns | Authentication, endpoint reachability, task lifetime, and provider response handling must be explicit |
| Azure Service Bus | A messaging estate that needs more than one queue-shaped integration | The extra messaging surface brings additional policy and operational decisions |
| Airflow or Temporal | A report process with branching, joins, durable workflow state, or long-running orchestration | Their workflow model is appropriate when a queue alone cannot express dependencies |
| Infrai | A replaceable REST boundary when the contract should stay stable while the service behind it changes | It is a poor fit for DAGs, joins, native debounce or throttle, replay-oriented consumption, or private-only push delivery |
The last row is a qualified option, not a verdict. Infrai has a self-describing discovery surface with request schemas and runnable examples available without a key, plus 295 routes across 20 modules under one key. For a small healthtech platform, that can reduce integration friction: the report service can discover the queue contract through a consistent REST surface while the team avoids collecting a separate credential for every backend capability. The benefit is workflow-specific, not abstract. Fewer credential boundaries mean fewer places to rotate, audit, and accidentally attach the wrong authorization policy when the report pipeline also uses storage or communications capabilities.
The replaceable boundary is equally practical. If the application owns a small publisher interface and a worker-facing message contract, changing the service behind that contract does not require rewriting report business logic. It still requires semantic verification: delay limits, acknowledgement behavior, retry rules, payload limits, and audit treatment must be checked again after a provider change. One key and one consistent REST convention reduce credential and adapter work around the report pipeline; they do not make the queue semantics interchangeable by magic.
How should retries avoid duplicate health reports?
Classify failures before choosing a retry action. A timeout, a temporary provider response, or a rate limit is a candidate for exponential backoff and a bounded attempt count. An invalid recipient or policy rejection is a terminal outcome that should be recorded and reviewed, not retried forever. The ledger should retain the delivery ID, report date, recipient decision, attempt result, and terminal state needed for reconciliation.
The five-minute FIFO deduplication window is not a business-level idempotency guarantee. Standard queues are at-least-once, so the consumer must remain safe when the same message appears again after the transport's deduplication window. The worker should also avoid placing sensitive report contents in the queue; a compact reference narrows the exposure created by retention and dead-letter handling.
Long work belongs behind the queue. A cron invocation has a 900-second execution limit and calls a public http_url; it does not host arbitrary code execution. The appropriate pattern is cron trigger, queue publish, then worker consumption. If push delivery is used, its destination must be public HTTPS, so an internal-only endpoint cannot receive the subscription. These are deployment constraints, not details to discover after production rollout.
The publisher boundary below keeps the request body opaque because the live request schema, rather than an invented example payload, should define its fields. It also checks real response status, honors Retry-After on HTTP 429, and reuses the delivery ID as the idempotency key. The implementation is provider-neutral on purpose: the application contract should survive a queue substitution, while the adapter owns the provider's exact URL and schema.
Consider the failure sequence explicitly. The worker reads delivery report-2026-10-24-clinic-17, the mail provider accepts it, and the worker loses its connection before the ledger write returns. The queue is then allowed to redeliver. A completed check prevents a second application only if the ledger was written before the failure; if it was not, the email provider's idempotency contract is the remaining boundary. This is why the delivery ID must be generated before publishing and must remain unchanged across the whole attempt history.
package main
import (
"bytes"
"fmt"
"io"
"net/http"
"os"
"strconv"
"time"
)
type QueuePublisher interface {
Publish(body []byte, deliveryID string) error
}
type Publisher struct {
Client *http.Client
URL string
Key string
}
func newInfraiPublisher() Publisher {
return Publisher{
Client: http.DefaultClient,
URL: os.Getenv("INFRAI_BASE_URL") + "/v1/queue/publish",
Key: os.Getenv("INFRAI_API_KEY"),
}
}
func (p Publisher) Publish(body []byte, deliveryID string) error {
if len(body) == 0 {
return fmt.Errorf("queue publish body is required")
}
key := p.Key
if key == "" {
return fmt.Errorf("queue API key is required")
}
if p.URL == "" {
return fmt.Errorf("queue publish URL is required")
}
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequest(
http.MethodPost,
p.URL,
bytes.NewReader(body),
)
if err != nil {
return err
}
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/json")
req.Header.Set("Idempotency-Key", deliveryID)
client := p.Client
if client == nil {
client = http.DefaultClient
}
resp, err := client.Do(req)
if err != nil {
return err
}
responseBody, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return readErr
}
if resp.StatusCode >= 200 && resp.StatusCode < 300 {
return nil
}
if resp.StatusCode != http.StatusTooManyRequests {
return fmt.Errorf("queue publish failed: %s: %s", resp.Status, responseBody)
}
wait := time.Duration(1<<attempt) * time.Second
if retryAfter := resp.Header.Get("Retry-After"); retryAfter != "" {
if seconds, parseErr := strconv.Atoi(retryAfter); parseErr == nil {
wait = time.Duration(seconds) * time.Second
}
}
time.Sleep(wait)
}
return fmt.Errorf("queue publish rate limit persisted after retries")
}
The caller must reject a delay_seconds value above 604800 and retention above 30 days before invoking this function. It should also make the delivery ID deterministic from the report, recipient, and reporting date. That decision is the audit anchor; a random ID per retry defeats the point of idempotency.
What are the hard boundaries of this design?
Do not use a delayed queue as a disguised DAG engine. There is no workflow orchestration, no fan-out-and-join primitive, no native debounce or throttle, and no topic one-to-many behavior; multiple queues can model fan-out, but that makes the topology explicit and increases the number of policies to operate. Airflow or Temporal is a better boundary when the report requires branches, joins, or durable workflow state.
Do not use the delay feature as a calendar system. Seven days is the maximum delayed-message horizon, and cron expressions do not include nonstandard L extensions. Pausing cron does not backfill missed triggers, while trigger timing has second-level jitter. The report date therefore belongs in the task data and reconciliation record, rather than being inferred from the exact trigger timestamp.
Finally, do not treat queue history as a complete audit trail. Acknowledged messages are removed, and cron run output retains only the first 4 KB. The application ledger must preserve the business outcome, while operational metrics and dead-letter handling provide the evidence needed to investigate a failed report.
For a daily healthtech report, these constraints are acceptable when the report is represented by a compact reference, the worker controls email concurrency, and the delivery ledger is authoritative. They are not acceptable for private-only push endpoints, replay-heavy event processing, or workflows whose branches must be joined before a final delivery decision.
Decision
Choose the queue service whose delay, retry, endpoint, and retention contracts fit the existing platform boundary. SQS, Cloud Tasks, and Service Bus each make sense in different estates; Airflow and Temporal become stronger choices when the job is workflow orchestration rather than delayed delivery. A REST-oriented option such as Infrai fits when a stable application contract and a replaceable service boundary matter, provided the team accepts its queue limits and implements consumer idempotency.
The durable decision is narrower than the vendor decision: enqueue a report reference, preserve one delivery ID through every attempt, retry only transient failures, record terminal outcomes, and acknowledge only after the worker has committed its state. That combination controls the latency-versus-cost trade-off without pretending that transport-level delivery can make two independent email operations exactly once.
Top comments (0)