Notifications
Alert users about events relevant to them across multiple delivery channels.
Options
Delivery Method*
User Control
Decision Points
Do users need to know about events immediately?
If yes
Use real-time delivery. Budget for WebSocket/SSE infrastructure.
If no
Polling is simpler and cheaper — pick an interval that matches your SLA.
Is this a mobile-first product?
If yes
Add mobile push (APNs/FCM). Plan for certificate rotation.
If no
Skip mobile push; web notifications or email cover most cases.
Do users often go offline and still need to receive notifications?
If yes
Add email fallback driven by a "last seen" timestamp. Send email only when the user has been offline >5 minutes to avoid spam.
If no
In-app real-time or polling is enough — email adds unsubscribe risk without upside.
Will you send multiple notification types with different urgency levels?
If yes
Adopt per-type granularity so users can mute digests without muting security alerts. Define the taxonomy up front.
If no
A single all-or-nothing toggle is enough and avoids preference-UI bloat.
Is notification volume high enough that users will complain about floods?
If yes
Batch similar notifications in a rolling window (e.g., "Alice and 12 others liked your post"). Entity + time-window grouping is the standard pattern.
If no
Deliver individually — grouping adds UI complexity that is not worth it at low volume.
Are any notifications security-critical or financially sensitive?
If yes
Require at-least-once delivery with persistent storage and retry. Pair with email fallback for the highest-urgency classes.
If no
Best-effort (fire-and-forget) is fine for social and informational notifications.
Do users have reasonable expectations of quiet hours / do-not-disturb?
If yes
Add a per-user quiet-hours window and a priority flag that lets critical alerts bypass it. Requires per-type granularity to know what is critical.
If no
Skip quiet hours — the added preference surface is not worth it for low-volume products.
Do users need to mark notifications as read / track what they have seen?
If yes
Persist notifications with a read state. Consider cross-device read-state sync via a server-side timestamp or event log.
If no
Ephemeral toast-style notifications are simpler and appropriate for low-stakes alerts.
Do you need delivery analytics (delivered, opened, clicked)?
If yes
Use a provider like Knock or Novu that tracks delivery funnel by channel. Essential if notifications drive revenue or retention KPIs.
If no
Skip the instrumentation — simple success/failure logs are enough.
Do users have multiple devices (web + mobile + desktop)?
If yes
Sync read-state across devices via a server-side last-read timestamp. Without this, users see the same notification over and over.
If no
Device-local read state is simpler and avoids backend round-trips.
Do you need SMS as a notification channel?
If yes
Use Twilio or Messagebird. Reserve SMS for high-priority alerts only — it is expensive per message and users churn fast on SMS spam.
If no
Skip SMS — push and email cover 99% of use cases at a fraction of the cost.
Are some notifications purely in-app / ephemeral (toast-style)?
If yes
Deliver via SSE/WebSocket without persisting — no storage, no retry, no read-state UI. Good for "Saved", "Uploaded" feedback.
If no
All notifications go through the durable pipeline with read-state tracking.
Do you need localized notification content (multi-language)?
If yes
Store notification templates with i18n keys and render per-recipient locale at send time. Avoid pre-rendered strings in the event.
If no
Hardcoded English strings are fine until you have non-English users.
Do you have more than 5 notification types or expect to add more regularly?
If yes
Invest in a template engine (Knock, MJML, or Handlebars) with versioned templates rather than hardcoded message strings.
If no
Hardcoded message strings in the sender are simpler and fine for a small stable set.
Do product/marketing teams need to preview and test-send notifications before release?
If yes
Build an internal preview tool with a test-recipient flag. Prevents production embarrassments.
If no
Skip — engineers can validate in staging until non-engineers start authoring templates.
Are there urgent notifications that must bypass quiet hours (security alerts, outages)?
If yes
Add a priority flag on notifications and skip DND for priority=urgent. Document this behavior so users expect it.
If no
Quiet hours apply uniformly — simpler and avoids abuse of the override.
Tradeoffs
Requires persistent connection infrastructure (e.g. Redis pub/sub, WebSocket server)
Higher server request volume; notifications may lag by poll interval
Requires APNs/FCM credentials and certificate management
Significantly more complex preference storage and UI