Compliance Event Dispatch: Auditable Email and SMS API Backoff Without Duplicate Sends

The compliance requirement for auditability of email and SMS notifications calls for a structured approach. First, place compliance notices in a queue. Assign a unique idempotency key per notice and channel, and log every attempt before any API call.

The delivery process should happen within the request handler on day one. Retries should begin later. Use a queue plus an append-only attempt ledger for strength and ease of querying compliance notices.

Audit records must answer specific questions: which business event triggered the notice, the selected destination and channel, content revision, start time of each attempt, and the terminal state observed. Store destination fingerprints instead of raw addresses. Keep the original business event ID separate from a provider receipt ID.

Implement a small state machine: pending, sending, accepted, delivered, permanent_failure, and suppressed. Each transition should have a timestamp and reason. Monitor a concrete sequence: an account triggers a notice at 09:00, the email adapter records acceptance on the first attempt, while the SMS adapter delays. At 09:02, the worker restarts. The notice is neither "sent" nor "failed," requiring two distinct states.

When reviewing the case, an operator sees the event ID, content revision, destinations, attempts, delays, and final outcomes chronologically. No log correlation is necessary, simplifying the process.

For Node.js event notifications, treat rate limiting as scheduling information, not permission to spin. Return a typed outcome that distinguishes acceptance, retryable delay, and permanent rejection. The dispatcher manages the retry policy, keeping transport-specific glue at the edge and making the policy testable without sending anything.

Use the server-provided delay when available; otherwise, calculate capped exponential backoff with jitter. Do not retry indefinitely. A compliance team needs a terminal state and an escalation path, not an immortal job.

Ensure a stable idempotency key is passed through the adapter when supported, plus a local uniqueness constraint on (noticeId, channel). If an API lacks an idempotent-send contract, serialize attempts for that key and reconcile ambiguous outcomes before retrying. This adds latency but avoids pretending distributed uncertainty vanished.

There is a crash window between the remote system accepting a request and the local worker storing the accepted state. Use a stable idempotency key and a local uniqueness constraint on (noticeId, channel) to close this gap. If no idempotent-send contract exists, serialize attempts for that key and reconcile outcomes before retrying.