Modern notification systems must orchestrate delivery across multiple channels, each with distinct characteristics, delivery semantics, cost structures, and technical requirements. Understanding these channels deeply is essential for making informed architectural decisions about routing, fallback strategies, and user experience optimization.

Each channel serves a unique purpose in the notification ecosystem. Push notifications excel at real-time engagement, email provides rich content and persistent records, SMS ensures reach even without internet connectivity, and in-app notifications deliver contextual experiences within your application. Together, they form a comprehensive communication strategy that reaches users wherever they are.

Mobile push notifications are the modern equivalent of a tap on the shoulder—they interrupt users to deliver time-sensitive information directly to their lock screens. Despite their deceptive simplicity from a user's perspective, push notifications involve a complex chain of systems: your backend, platform-specific gateway services, device operating systems, and finally the notification rendering system.

The Push Notification Flow:

1. User opts in — App requests notification permission; OS generates a device token
2. Token registered — App sends device token to your backend for storage
3. Event occurs — Your system decides to notify the user
4. Message constructed — Notification payload created with title, body, data, actions
5. Sent to gateway — Message sent to APNs (iOS) or FCM (Android)
6. Gateway delivers — Platform service delivers to device over persistent connection
7. Device renders — OS displays notification based on user settings and app state

Web Push enables browser-based notifications that work even when your website isn't open. Built on open standards (Web Push Protocol, VAPID), it provides a platform-agnostic approach to reaching users on desktop and mobile browsers.

Web Push Protocol Stack:

1. Push API — JavaScript API for subscribing to push notifications
2. Service Workers — Background scripts that receive and display notifications
3. Web Push Protocol (RFC 8030) — HTTP-based protocol for message delivery
4. VAPID (RFC 8292) — Voluntary Application Server Identification for authentication
5. Message Encryption (RFC 8291) — End-to-end encryption of notification payloads

Subscription Flow:

// 1. Register service worker
const registration = await navigator.serviceWorker.register('/sw.js');

// 2. Request notification permission
const permission = await Notification.requestPermission();

// 3. Subscribe to push
const subscription = await registration.pushManager.subscribe({
  userVisibleOnly: true,
  applicationServerKey: urlBase64ToUint8Array(VAPID_PUBLIC_KEY)
});

// 4. Send subscription to your server
await fetch('/api/push/subscribe', {
  method: 'POST',
  body: JSON.stringify(subscription)
});

Service Worker Handler:

// sw.js - Service Worker
self.addEventListener('push', function(event) {
  const payload = event.data ? event.data.json() : {};
  
  const options = {
    body: payload.body,
    icon: payload.icon || '/icon-192.png',
    badge: '/badge.png',
    data: payload.data,
    actions: payload.actions || [],
    tag: payload.tag, // For notification replacement
    renotify: payload.renotify || false
  };

  event.waitUntil(
    self.registration.showNotification(payload.title, options)
  );
});

self.addEventListener('notificationclick', function(event) {
  event.notification.close();
  
  const url = event.notification.data?.url || '/';
  event.waitUntil(
    clients.openWindow(url)
  );
});

Key Considerations:

• Subscriptions can be invalidated by browser updates or user actions
• No delivery receipts available; track opens via notification clicks only
• Some browsers require user interaction before requesting permission
• Background sync and periodic sync can complement push for resilience

Email remains the most universal digital communication channel, reaching virtually every internet user regardless of device or platform. For notification systems, email serves dual purposes: transactional messages (receipts, confirmations, alerts) and marketing communications (newsletters, promotions, updates).

Email Delivery Chain:

1. Composition — Your system generates email content from templates
2. Submission — Email sent to your outbound mail server or ESP
3. Relay — Message routed through internet mail infrastructure
4. Reception — Recipient's mail server receives and processes
5. Spam Filtering — Content analyzed for spam, phishing, malware
6. Inbox Delivery — Message placed in inbox, promotions, or spam folder
7. Rendering — Email client displays message (with client-specific quirks)

Deliverability Factors:

Email deliverability—getting messages to the inbox rather than spam—depends on:

• Sender Reputation — IP and domain reputation built over time through sending volume, bounce rates, spam complaints, and engagement
• Authentication — SPF, DKIM, and DMARC records that prove you're authorized to send for your domain
• Content Quality — Avoiding spam triggers, maintaining text-to-image ratio, including unsubscribe links
• List Hygiene — Removing bounced addresses, inactive subscribers, and spam traps
• Engagement — High open and click rates signal valuable content

Bounce Handling:

Bounces occur when email delivery fails:

• Hard Bounces — Permanent failures (address doesn't exist, domain invalid). Remove immediately from your list.
• Soft Bounces — Temporary failures (mailbox full, server down). Retry with exponential backoff; convert to hard bounce after multiple failures.
• Complaint — User marked email as spam. Remove immediately and investigate.

Most ESPs provide webhook notifications for bounces. Your system must process these in near-real-time to maintain sender reputation.

SMS (Short Message Service) provides the most reliable reach—it works on any phone, doesn't require internet connectivity or app installation, and has near-universal read rates (98%+ open rate). However, SMS is also the most expensive channel and subject to strict regulations.

SMS Delivery Path:

1. Message Creation — Your system generates SMS content (160 character limit for GSM-7, 70 for Unicode)
2. API Submission — Message sent to SMS aggregator (Twilio, Nexmo, etc.)
3. Carrier Routing — Aggregator routes to appropriate cellular carrier
4. Delivery — Carrier delivers to recipient's phone
5. Delivery Receipt — Optional confirmation of delivery (DLR)

Short Codes vs. Long Codes vs. Toll-Free:

• Short Codes (5-6 digits) — High throughput (100+ msg/sec), expensive to lease ($500-1000/month), carrier approved, best for high-volume transactional
• Long Codes (10-digit phone numbers) — Standard phone numbers, very limited throughput (1 msg/sec per number), cheapest option, P2P only
• Toll-Free Numbers — Moderate throughput (3 msg/sec), monthly fee, requires registration, good for business messaging
• 10DLC (10-Digit Long Code) — Carrier-registered long codes, variable throughput based on trust score, requires campaign registration

OTP (One-Time Password) Considerations:

SMS-based 2FA is common but has security considerations:

• Vulnerable to SIM swapping attacks
• SS7 vulnerabilities allow interception
• Delivery delays can frustrate users
• Consider time-based OTP (TOTP) apps as alternative
• Always implement rate limiting on OTP generation

In-app notifications appear within your application while the user is actively using it. Unlike push notifications that interrupt users externally, in-app notifications provide contextual, timely information within the user's current workflow. They're the least intrusive channel but only reach users who are already engaged with your application.

Real-Time Delivery Architecture:

In-app notifications require real-time delivery to connected clients. Common approaches include:

1. WebSocket Connections:

// Client-side WebSocket connection
const ws = new WebSocket('wss://notifications.example.com/ws');

ws.onmessage = (event) => {
  const notification = JSON.parse(event.data);
  displayNotification(notification);
};

// Server-side: broadcast to user's connected sessions
async function sendInAppNotification(userId, notification) {
  const sessions = await getActiveWebSockets(userId);
  for (const session of sessions) {
    session.send(JSON.stringify(notification));
  }
}

2. Server-Sent Events (SSE):

• Simpler than WebSocket, unidirectional
• Better for notification-only use cases
• Automatic reconnection built into browser API

3. Long Polling:

• Fallback for environments without WebSocket support
• Higher latency and server load
• Still used for maximum compatibility

Choosing the right channel for each notification type requires balancing urgency, user preferences, cost, and deliverability. A well-designed notification system uses intelligent channel selection based on multiple factors.

Intelligent Routing Factors:

1. User Preferences — Always respect explicit user choices for channel and frequency

2. Device State:

   • Is push token valid and recent?
   • Is user currently active in app (prefer in-app)?
   • What's the user's timezone and local time?

3. Notification Urgency:

   • Critical: Multi-channel simultaneously (fraud alert via SMS + Push + Email)
   • High: Fastest available channel with fallback
   • Normal: Preferred channel with gentle fallback
   • Low: Batch for digest or next engagement

4. Cost Optimization:

   • Prefer push/in-app over SMS when both are viable
   • Use SMS only for high-value or critical notifications
   • Consider cost caps per user per period

Integrating with external notification providers requires careful architecture to handle rate limits, failures, cost optimization, and provider portability.

Multi-Provider Strategy:

For high availability, consider multiple providers per channel:

Email Providers:
├── Primary: SendGrid (70% of traffic)
├── Secondary: Amazon SES (25% of traffic)
└── Tertiary: Mailgun (5%, warm standby)

SMS Providers:
├── Primary: Twilio
├── Secondary: Vonage (failover only)
└── Carrier-specific: Direct carrier APIs for volume discounts

Benefits of Multi-Provider:

• Resilience against single provider outages
• Cost optimization through provider competition
• Improved deliverability (different providers have different strengths)
• Negotiating leverage with providers

Challenges:

• Increased complexity in routing logic
• Inconsistent analytics across providers
• Different feature sets may limit unified APIs

We've explored the four primary notification channels in depth. Each serves distinct purposes and comes with unique technical requirements, costs, and constraints.

What's Next:

With a deep understanding of individual channels, we'll now explore how to route notifications through this multi-channel system. The next page covers Notification Routing—the logic that determines which channel(s) to use for each notification, how to handle priorities, and implementing sophisticated routing rules.