Notification Working Principle

1. Single Surface: Transactional Email

There is exactly one notification surface: auth transactional email, delivered via Resend. No in-app inbox, no push, no admin notification feed.

2. Fire-and-Forget Delivery

Email sends are not tracked for read/delivered/seen state. A SEND_EMAIL job either succeeds (Resend accepts it) or fails (BullMQ retries per the queue's configured attempts/backoff, then the job is retained as failed for inspection).

3. Idempotency

AuthEmailService sets a deterministic jobId for OTP-delivery jobs (see enqueueOtpDelivery()) so a retried request does not duplicate an in-flight send. Plain transactional emails (password reset, verify email) do not need this — a duplicate send there is a harmless annoyance, not a correctness problem — unlike the OTP path, which participates in a rate-limited security flow.

4. XSS Safety

Every dynamic value interpolated into an email's HTML body (name, OTP code, links) is passed through escapeHtml() in the shared layout before being embedded into the template.

5. No Read State, No Presence, No Realtime

The prior version of this page described per-surface read state, presence-aware push suppression, and realtime fanout — infrastructure (an in-app inbox, push notifications, WebSocket rooms) that has been fully removed from this codebase. None of it applies to the current auth-only email surface.