7 Event Notification Controls — Node.js Email SMS API Polling and Retry
Short answer: for B2B SaaS event notifications, use an email and SMS API to create one durable delivery ledger, then sample the telemetry around it. Polling and retry belong to that ledger's operational layer. The integration question is effort: can the team explain a missed compliance notice without retaining every response?
1. How should event notifications use an email and SMS API for polling?
Start with the bytes that the bill actually stores. Use events x attempts x polls x response bytes as a working model. Fifty thousand notices, two retries, and six polls create 900,000 observations before indexing. I read log lines as bytes stored and labels as cardinality.
Keep notification ID, channel, attempt, request time, correlation ID, state, next check, and failure class in the ledger. Keep recipient identity there too, behind access control. An email address as a metric label is expensive and inappropriate; channel, outcome, environment, and bounded failure_class are useful labels.
The ledger is not a transcript store. It is a decision record.
That is the first deliberate loss. Dropping raw poll responses removes a complete transcript, but preserves what an auditor needs to establish: what was attempted, when, and what state was last observed. Do not duplicate the full message body or unbounded error text in every row. A template revision or content hash is usually a more useful reference, subject to policy.
2. What does a Node.js worker do after a 429?
A 429 is a scheduling signal, not a terminal delivery result. Honor Retry-After when present; otherwise use bounded exponential backoff with jitter. Record the retry hint and selected delay.
curl --request GET \\ --url 'https://api.example.invalid/v1/email/event/list' \\ --header 'Accept: application/json' \\ --header 'Authorization: Bearer ${DELIVERY_TOKEN}' The worker classifies before scheduling: a pending success gets another check, a 429 gets a bounded next check, a timeout follows the retry budget, and a terminal rejection stops polling. Five attempts over 30 minutes is a worked policy, not a universal constant; the compliance deadline should decide it.
Use one scheduler authority. If both a request handler and a background worker enqueue retries, duplicate attempts become difficult to explain. A unique notification_id:attempt key makes that operation idempotent at the database boundary. Keep state transitions, not fixed snapshots: unchanged state updates last_checked_at in operational storage, while a change appends old state, new state, observation time, and correlation ID.
Polling is a poor fit when a legal deadline is shorter than the channel's normal status delay, or when the external API offers no stable correlation ID. In those cases, polling can create a reassuring record of activity without proving delivery. A callback, queue consumer, or a different channel may require more integration work, but the evidence boundary is clearer. That is a limitation of the method, not a defect to hide.
3. How do polling, retention, and sampling affect auditability?
Acceptance is not delivery. Email and SMS need explicit, versioned state maps. A delayed status can hide the exact transition moment, so retain observation time and polling-policy version even when routine responses are discarded.
Keep all terminal failures and 429 responses in structured logs. Sample routine success traces after recording their transition. Six unchanged polls should not become six permanent audit events. I would rather lose a routine success trace than lose the failure record that explains a missed deadline.
The useful number is not “how many logs did the worker write?” It is “how many future decisions can the retained records support?” A terminal failure needs enough context to identify the notice, channel, attempt, policy, and external correlation. A successful, unchanged poll usually needs only its latest observation time. Retaining both at the same granularity makes the expensive, low-value path look normal.
Retention should answer a future question. Keep immutable notice and attempt records for the period required by organizational policy; keep retry state until reconciliation ends; retain detailed success traces for less time than terminal failure evidence unless an investigation extends them. The cost is losing a complete poll transcript. The benefit is an evidence trail that stays queryable as volume grows.
4. Which failure cases should the integration test prove?
Test pending acceptance, 429 with and without Retry-After, timeout, permanent rejection, and duplicate workers. Assert ledger transitions and retry budget, not only HTTP status. A sequence fixture exposes accidental fixed-interval logging and proves that a retry did not create a second business intent.
Keep the external contract test at the integration boundary and scheduler tests against a deterministic fake endpoint. Neither needs a live recipient. Keep less. That makes the remaining evidence easier to inspect.
An audit trail also has an access cost. The more message content and recipient data copied into logs, the more places need review, redaction, and controlled access. A narrow ledger reduces that surface while leaving the operational question answerable.
No magic.
Consider a notice that enters the system at 09:00, receives an accepted response at 09:01, stays pending through three checks, and is rejected at 09:18. The useful audit story is not six copies of a JSON response. It is the intent at 09:00, the attempt and correlation ID at 09:01, the pending observations with their policy version, and the terminal rejection at 09:18. An investigator can ask why the next check was scheduled, which retry budget applied, and whether the rejection stopped further work. Those questions require timestamps, states, and identifiers. They do not require every header or every unchanged response body. If the team later needs the raw response for a dispute, it can preserve that evidence under the organization's controlled retention policy rather than duplicating it into metrics, traces, and application logs by default.