Requirements: Multi-Channel Notifications - Notification System | OneNoughtOne

0/273

System Design (HLD)Notification System

Design a Notification System

LevelAdvanced

Duration90 mins

TopicNotification System

1 / 6

Requirements: Multi-Channel Notifications

The Invisible Backbone of User Engagement

Every modern application, from social networks to banking apps, relies on notifications to keep users informed and engaged. When you receive a push notification about a friend's message, an email receipt for your purchase, or an SMS verification code, you're witnessing a sophisticated distributed system in action—one that must deliver billions of messages per day with remarkable reliability.

Notification systems appear deceptively simple on the surface. Send a message when something happens—how hard can that be? But beneath this simplicity lies extraordinary complexity: coordinating multiple delivery channels, respecting user preferences, handling failures gracefully, preventing abuse, and scaling to millions of concurrent users while maintaining sub-second delivery latency.

What You Will Learn

This page establishes the comprehensive requirements for designing a notification system at scale. You'll understand the functional and non-functional requirements, explore real-world use cases across different industries, and learn the key constraints that make notification system design one of the most challenging and interesting problems in system design.

Understanding Notification Systems

A notification system is a platform that enables applications to communicate with users through various channels in a timely, reliable, and personalized manner. Unlike direct request-response communication, notifications are asynchronous, event-driven messages that inform users about events, actions, or information they care about.

The Core Mission:

At its heart, a notification system must accomplish three fundamental objectives:

Deliver the right message — Content that is relevant, actionable, and valuable to the recipient
Through the right channel — The delivery method that best matches the urgency and nature of the message
At the right time — Respecting user preferences, time zones, and contextual appropriateness

Notification Channels Overview
Channel	Latency	Reach	Cost	Best For
Push (Mobile)	Milliseconds	Users with app installed	Very Low	Real-time alerts, time-sensitive updates
Push (Web)	Milliseconds	Users with browser opt-in	Very Low	Web app engagement, breaking news
Email	Seconds to Minutes	All users with email	Low	Detailed content, receipts, digests
SMS	Seconds	All users with phone	High	Critical alerts, 2FA, verification
In-App	Milliseconds	Active app users only	Minimal	Feature announcements, contextual tips
Voice Call	Seconds	All users with phone	Very High	Emergency alerts, urgent verification

Multi-Channel Requirement:

Modern notification systems must support multiple channels simultaneously because:

Different messages require different channels (2FA codes via SMS, marketing via email)
Users have varying preferences for how they want to be reached
Redundancy ensures critical messages get delivered even if one channel fails
Channel availability varies by geography, device, and user state (online vs offline)

This multi-channel nature introduces significant complexity. A single notification event might need to be routed to multiple channels, formatted differently for each, delivered with channel-specific retry logic, and tracked for engagement across all channels.

Functional Requirements

Before diving into architecture, we must precisely define what the notification system must do. Functional requirements describe the features and capabilities the system must provide.

Core Functional Requirements

•Multi-Channel Delivery — Support push notifications (iOS/Android/Web), email, SMS, in-app notifications, and extensibility for future channels (WhatsApp, Slack, voice)
•Template Management — Create, version, and manage notification templates with dynamic variable substitution (e.g., 'Hello {{user_name}}, your order {{order_id}} is ready')
•Targeting and Segmentation — Send notifications to individual users, user segments, topics, or broadcast to all users
•Scheduling — Support immediate delivery, scheduled delivery at specific times, and recurring notifications
•User Preferences — Allow users to control which notifications they receive and through which channels
•Delivery Status Tracking — Track notification lifecycle: created → queued → sent → delivered → opened/clicked
•Analytics and Reporting — Provide delivery metrics, engagement rates, failure analysis, and A/B testing capabilities

Priority-Based Delivery

Critical notifications (security alerts, transaction confirmations) must have priority delivery paths that bypass batching and rate limiting, ensuring delivery even under high load. Non-critical notifications (marketing, social updates) can be batched and rate-limited to prevent user fatigue.

Advanced Functional Requirements

•Internationalization (i18n) — Support for multiple languages, locale-aware formatting (dates, currencies), and right-to-left languages
•Rich Media Support — Images, action buttons, deep links, and interactive elements in push and email notifications
•Notification Grouping — Intelligent bundling of similar notifications (e.g., '5 people liked your post' instead of 5 separate notifications)
•Quiet Hours — Respect user-defined do-not-disturb schedules and time zone-aware delivery windows
•Read Receipts and Actions — Track when users view notifications and capture action button clicks
•Fallback Chains — If push delivery fails, automatically attempt email; if email bounces, try SMS
•Campaign Management — Support marketing campaigns with audience targeting, scheduling, and performance tracking

Non-Functional Requirements

Non-functional requirements define the quality attributes of the system—how well it performs its functions. For notification systems, these requirements are particularly demanding due to the high volume, real-time nature, and user-facing impact of the service.

Non-Functional Requirements at Scale
Requirement	Target	Rationale
Throughput	1M+ notifications/second	Handle peak loads during major events, promotions, or viral content
Latency (P99)	< 500ms for high-priority	Time-sensitive notifications lose value if delayed significantly
Availability	99.99% (52 min downtime/year)	Notifications are critical; outages impact user trust and business
Durability	Zero message loss	Every notification request must be persisted before acknowledgment
Delivery Rate	99.9% successful delivery	Accounting for unreachable devices, invalid tokens, bounced emails
Scalability	10x growth without re-architecture	System must handle organic growth and sudden spikes

Reliability Considerations:

Notification systems must handle a unique reliability challenge: external dependencies. Unlike purely internal systems, notifications depend on:

Push Notification Gateways — Apple Push Notification Service (APNs), Firebase Cloud Messaging (FCM), Web Push Protocol
Email Providers — SendGrid, Amazon SES, Mailgun, or self-hosted SMTP servers
SMS Carriers — Twilio, Nexmo, or direct carrier connections

Each external provider has its own rate limits, failure modes, delivery semantics, and SLAs. The notification system must abstract these differences while providing consistent reliability guarantees to internal clients.

At-Least-Once vs. Exactly-Once Delivery

Most notification systems provide at-least-once delivery semantics because exactly-once is extremely difficult with external providers. This means duplicate notifications are possible during failure recovery. The system must implement deduplication at the application layer to minimize duplicates while prioritizing deliverability.

Quality Attributes Deep Dive

•Consistency — User preferences must be strongly consistent; a user who just opted out must not receive further notifications of that type
•Idempotency — Processing the same notification request multiple times should not result in duplicate deliveries
•Observability — Every notification must be traceable from request to delivery, with clear failure reasons when delivery fails
•Cost Efficiency — SMS and voice are expensive; the system must optimize channel selection and prevent wasteful retries
•Security — Protect sensitive notification content, prevent unauthorized access to notification APIs, and ensure data privacy compliance (GDPR, CCPA)
•Extensibility — Adding new channels or notification types should not require significant re-architecture

Scale and Volume Analysis

Understanding the scale of notification systems is crucial for making informed architectural decisions. Let's analyze the volume characteristics of a notification system serving a platform like Facebook, Twitter, or a major e-commerce site.

Scale Assumptions for Design

Assume we're designing for a social platform with 500 million monthly active users (MAU), 100 million daily active users (DAU), averaging 10 notifications received per user per day. This gives us a baseline of 1 billion notifications per day, or approximately 12,000 notifications per second on average, with peak loads of 5-10x during major events.

Back-of-Envelope Calculations
Metric	Calculation	Result
Daily Notifications	100M DAU × 10 notifications/user	1 billion/day
Average QPS	1B / 86,400 seconds	~12,000 notifications/second
Peak QPS (10x)	12,000 × 10	~120,000 notifications/second
Storage (1 month)	1B × 30 days × 500 bytes/notification	~15 TB/month
Device Tokens	500M users × 2 devices avg	1 billion device tokens
Email Addresses	500M users × 1 email	500 million emails

Traffic Patterns:

Notification traffic is highly variable and exhibits distinct patterns:

Diurnal Patterns — Traffic peaks during waking hours in major time zones, with valleys overnight. A global platform sees rolling peaks as different regions wake up.
Event-Driven Spikes — Breaking news, viral content, or major sports events can cause 10-100x normal traffic within seconds.
Scheduled Campaigns — Marketing email blasts at 9 AM can create massive synchronized load.
Cascade Effects — A viral post generates comments, which generate notifications, which generate more engagement—a positive feedback loop.

Infrastructure Implications:

These patterns require:

Elastic scaling to handle sudden spikes
Queue-based architecture to buffer traffic surges
Rate limiting to protect downstream providers
Geographic distribution to handle time zone shifts efficiently

Push Notification Scale

•Apple APNs: Rate limits per token
•FCM: 500 messages/second per project (burstable)
•Web Push: Varies by browser vendor
•Device tokens expire and must be refreshed
•Payload size limits: ~4KB APNs, ~4KB FCM

Email/SMS Scale

•Email providers throttle new senders
•IP warming required for high volume
•Bounce rates affect sender reputation
•SMS costs $0.005-0.05 per message
•International SMS requires carrier agreements

Real-World Use Cases

Notification systems serve vastly different use cases across industries. Understanding these use cases helps prioritize features and make appropriate trade-offs during design.

Social Engagement Notifications (Facebook, Twitter, Instagram)

Social platforms generate massive notification volumes from user interactions:

Likes, comments, shares — High volume, low priority, excellent candidates for batching
Friend requests, follows — Medium priority, require user action
Mentions, tags — Higher priority, user expects timely delivery
Direct messages — High priority, real-time delivery expected
Live events — Breaking news, live streams starting

Challenges:

Viral content creates notification storms (one post generating millions of notifications)
Users follow power users (celebrities with millions of followers)
Must balance engagement with notification fatigue
Complex social graph makes fanout expensive

Design Constraints and Challenges

Designing a notification system involves navigating numerous constraints and challenges that don't exist in simpler systems. Understanding these upfront prevents costly re-architecture later.

External Provider Constraints

•Rate Limits — APNs, FCM, and email providers impose strict rate limits. Exceeding them causes temporary blocks or permanent bans.
•Token Expiration — Push tokens expire when users uninstall apps, switch devices, or revoke permissions. Stale tokens waste resources and hurt metrics.
•Delivery Guarantees — Providers offer 'fire and forget' semantics. They don't guarantee delivery, only acceptance of the message.
•Feedback Delays — Bounce notifications, delivery receipts, and unsubscribe callbacks may arrive hours or days later.
•Cost Variability — SMS costs vary dramatically by destination country ($0.001 to $0.10+ per message).

The Celebrity Problem

When a celebrity with 50 million followers posts content, the notification system must generate 50 million notifications instantly. This 'fanout' problem is one of the hardest challenges in notification system design. Do you generate all 50 million notifications synchronously (hot path becomes slow) or asynchronously (delivery delay)? Neither option is ideal, requiring sophisticated fanout strategies.

User Experience Challenges

•Notification fatigue leads to opt-outs
•Poorly timed notifications annoy users
•Duplicate notifications erode trust
•Irrelevant notifications hurt engagement
•Delayed notifications lose value

Technical Challenges

•Maintaining ordering for related notifications
•Handling device timezone complexity
•Multi-device deduplication (same user, multiple devices)
•A/B testing notification content and timing
•Graceful degradation during partial outages

Compliance and Legal Constraints:

Notification systems must navigate a complex regulatory landscape:

GDPR (Europe) — Right to erasure requires purging all notification history for a user. Consent must be explicit and withdrawable.
CCPA (California) — Users can request access to all data, including notification history.
CAN-SPAM (US) — Marketing emails must include unsubscribe links honored within 10 days.
TCPA (US) — SMS requires prior express consent; violations can cost $500-$1,500 per message.
PECR (UK) — Additional restrictions on electronic marketing.

These regulations affect data retention, consent management, and unsubscribe handling—all of which must be built into the system from the start.

Defining Success Metrics

A well-designed notification system must be measurable. Defining success metrics upfront ensures alignment between engineering decisions and business outcomes.

Key Performance Indicators (KPIs)
Metric	Definition	Target
Delivery Rate	Notifications successfully delivered / Total sent	99.9% for transactional, > 95% for marketing
Time-to-Delivery (P50)	Median time from request to delivery	< 100ms for push, < 5s for email
Time-to-Delivery (P99)	99th percentile delivery time	< 1s for push, < 30s for email
Open Rate	Notifications opened / Delivered	Varies by type (10-40% typical)
Click-Through Rate	Action clicks / Opens	5% for actionable notifications
Opt-Out Rate	Unsubscribes / Delivered (rolling 7 days)	< 0.1% (lower is better)
Bounce Rate	Hard bounces / Email sent	< 2% (above indicates list hygiene issues)
Duplicate Rate	Duplicate deliveries / Total deliveries	< 0.01% (near-zero target)

Leading vs. Lagging Indicators

Delivery rate and time-to-delivery are leading indicators—they measure system health directly. Open rate and click-through rate are lagging indicators—they measure content and targeting effectiveness. A high-performing notification system requires excellence in both categories.

Operational Metrics

•Queue Depth — Messages waiting in each channel queue. Growing queues indicate capacity issues or downstream problems.
•Processing Lag — Time between message enqueue and processing start. Should remain stable under load.
•Provider Error Rates — Errors from APNs, FCM, email providers. Early warning of integration or quota issues.
•Token Refresh Rate — Frequency of push token updates. Sudden spikes may indicate app update or provider issues.
•Preference Lookup Latency — Time to fetch user notification preferences. Critical path that must remain fast.

Requirements Summary

Let's consolidate everything we've covered into a clear requirements specification that will guide our architecture decisions in subsequent pages.

Requirements Checklist

•Multi-Channel Support — Push (iOS, Android, Web), Email, SMS, In-App, with extensibility for future channels
•High Throughput — Handle 100K+ notifications/second with ability to scale for peak events
•Low Latency — P99 delivery under 500ms for priority notifications
•High Availability — 99.99% uptime with graceful degradation, no single points of failure
•Durability — Zero message loss; all requests persisted before acknowledgment
•User Preferences — Per-user, per-channel, per-notification-type preference management
•Rate Limiting — Protect users from notification overload and system from abuse
•Deduplication — Near-zero duplicate notifications despite at-least-once delivery semantics
•Batching — Intelligent grouping of similar notifications to reduce user fatigue
•Analytics — Comprehensive tracking of delivery, engagement, and system health

What's Next:

With requirements clearly defined, we'll now dive into the channels themselves. The next page explores Push, Email, SMS, and In-App delivery channels in detail—their protocols, providers, best practices, and failure modes. Understanding each channel's characteristics is essential for designing an effective multi-channel routing strategy.

Page Complete

You now have a comprehensive understanding of notification system requirements. You've learned about functional and non-functional requirements, scale analysis, industry use cases, design constraints, and success metrics. This foundation prepares you for the architectural deep dives ahead.