When a notification event occurs—a new message, a security alert, a friend request—a cascade of decisions must happen in milliseconds: Which users should receive this notification? Through which channels? With what priority? Should it be delivered immediately or batched? This decision-making layer is notification routing, and it's the brain of any notification system.

Routing transforms raw notification events into targeted, channel-specific deliveries. A poorly designed routing layer creates frustrated users (too many notifications through wrong channels) and wasted resources (redundant deliveries, expensive SMS for non-critical events). A well-designed routing layer feels invisible—users receive exactly the right information through the right channel at the right time.

The routing layer sits between notification producers (services that trigger notifications) and channel-specific delivery systems. Its responsibilities include recipient resolution, channel selection, priority assignment, and delivery scheduling.

Components of the Routing Layer:

1. Routing Queue — Ingests notification requests from all producer services. Provides buffering during traffic spikes and ensures durability.

2. Rules Engine — Evaluates routing rules to determine how each notification should be processed. Rules can be based on notification type, user attributes, time of day, etc.

3. Preference Service — Fetches and caches user notification preferences. Critical path that must be highly available and low-latency.

4. Channel Selector — Determines which channel(s) to use based on preferences, notification type, delivery requirements, and channel availability.

5. Priority Router — Routes notifications to channel-specific queues with appropriate priority levels, ensuring critical notifications skip the line.

Not all notifications are created equal. A security alert about a compromised account is infinitely more important than a notification about someone liking a post. Priority-based routing ensures critical notifications receive immediate processing while less urgent ones can wait or be batched.

Implementing Priority Queues:

Priority routing requires separate queues or queue priorities:

class NotificationRouter:
    def __init__(self):
        self.queues = {
            'critical': PriorityQueue(workers=50),   # P0
            'high': PriorityQueue(workers=30),       # P1
            'normal': PriorityQueue(workers=20),     # P2-P3
            'bulk': PriorityQueue(workers=5),        # P4
        }
    
    def route(self, notification: Notification):
        priority = self.determine_priority(notification)
        queue_name = self.priority_to_queue(priority)
        
        self.queues[queue_name].enqueue(notification)
    
    def determine_priority(self, notification: Notification) -> int:
        # Check explicit priority from producer
        if notification.priority is not None:
            return notification.priority
        
        # Derive from notification type
        return self.priority_rules.get(
            notification.type, 
            Priority.NORMAL
        )

Worker Allocation:

Different priority levels should have dedicated worker pools:

• Critical queue: Most workers, always available capacity
• High queue: Generous allocation, auto-scales aggressively
• Normal queue: Standard allocation, scales based on depth
• Bulk queue: Minimal workers, processes during off-peak

A routing rules engine evaluates conditions against notification context to make routing decisions. Well-designed rules engines enable product teams to modify routing behavior without engineering changes.

Rule Structure:

Each rule consists of conditions (when to apply) and actions (what to do):

{
  "rule_id": "security-alerts-multi-channel",
  "priority": 1,
  "conditions": {
    "all": [
      {"fact": "notification_type", "operator": "in", "value": ["password_reset", "login_from_new_device", "account_compromised"]},
      {"fact": "user.has_phone", "operator": "equals", "value": true}
    ]
  },
  "actions": [
    {"type": "set_priority", "value": "critical"},
    {"type": "add_channel", "value": "sms"},
    {"type": "add_channel", "value": "push"},
    {"type": "add_channel", "value": "email"},
    {"type": "bypass_rate_limit", "value": true}
  ]
}

Rule Evaluation Order:

Rules should be evaluated by priority, with first-match or all-match semantics:

1. First-Match — Stop after first matching rule (simpler, may miss combinations)
2. All-Match — Apply all matching rules, merge actions (more flexible, requires conflict resolution)

Most notification systems use all-match with priority-based conflict resolution: if two rules set different priorities, the higher priority wins.

When a single event needs to notify many users—a celebrity posts, a breaking news alert goes out, a service outage affects all customers—the notification system must efficiently fan out to potentially millions of recipients. This is one of the most challenging aspects of notification system design.

Hybrid Approach (Most Common):

Real-world systems use hybrid strategies:

def fanout_notification(event: Event, audience: Audience):
    audience_size = audience.get_size()
    
    if audience_size <= 1000:
        # Small audience: immediate fanout
        return fanout_on_write(event, audience)
    
    elif audience_size <= 100_000:
        # Medium audience: async fanout workers
        return async_fanout(event, audience)
    
    else:
        # Large audience: hybrid approach
        # Immediate fanout to active users
        active_users = audience.get_active_subset(max_size=10_000)
        fanout_on_write(event, active_users)
        
        # Lazy fanout for rest (when they come online)
        store_pending_event(event, audience.exclude(active_users))
        
        # Background worker continues fanout
        schedule_background_fanout(event, audience)

Fanout Scaling Techniques:

1. Partition by User — Distribute fanout across worker pools partitioned by user ID hash
2. Batch Processing — Group recipients for bulk API calls to providers (FCM supports 500 tokens per request)
3. Priority Segmentation — Fanout to most engaged users first, then rest
4. Rate Limiting — Spread fanout over time to avoid overwhelming providers
5. Delta Fanout — For audience updates, only process adds/removes, not full recalculation

Beyond static rules, advanced notification systems use machine learning and real-time signals to optimize channel selection for each user and notification combination.

ML-Based Channel Selection:

A machine learning model can predict the best channel for each notification:

class ChannelPredictor:
    def __init__(self, model_path: str):
        self.model = load_model(model_path)
    
    def predict_channel(self, notification: Notification, user: User) -> ChannelSelection:
        features = self.extract_features(notification, user)
        
        # Model outputs probability for each channel
        probabilities = self.model.predict(features)
        
        # Map to channel selection
        channels = []
        for channel, prob in probabilities.items():
            if prob > self.threshold(channel):
                channels.append(ChannelConfig(
                    channel=channel,
                    confidence=prob,
                    delay=self.compute_optimal_delay(channel, user)
                ))
        
        return ChannelSelection(
            channels=sorted(channels, key=lambda c: -c.confidence),
            fallback_chain=self.generate_fallbacks(channels)
        )
    
    def extract_features(self, notification: Notification, user: User) -> dict:
        return {
            'notification_type': notification.type,
            'hour_of_day': datetime.now(user.timezone).hour,
            'user_last_active_channel': user.last_active_channel,
            'push_open_rate_7d': user.metrics.push_open_rate_7d,
            'email_open_rate_7d': user.metrics.email_open_rate_7d,
            'days_since_last_notification': user.metrics.days_since_last,
            'user_tier': user.subscription_tier,
            'device_type': user.primary_device_type,
            # ... many more features
        }

A/B Testing Channels:

Continuously experiment with channel strategies:

• Randomly assign users to channel strategy variants
• Measure engagement metrics per variant
• Gradually roll out winning strategies
• Account for long-term effects (notification fatigue)

Sophisticated routing requires maintaining state about notifications in flight, delivery attempts, and user interactions. This state enables features like fallback chains, acknowledgment tracking, and duplicate suppression.

Notification Lifecycle States:

┌─────────────┐     ┌──────────────┐     ┌────────────┐
│   CREATED   │ ──▶ │    QUEUED    │ ──▶ │   ROUTED   │
└─────────────┘     └──────────────┘     └────────────┘
                                               │
                    ┌──────────────────────────┼──────────────────────────┐
                    │                          │                          │
                    ▼                          ▼                          ▼
            ┌──────────────┐           ┌──────────────┐           ┌──────────────┐
            │ SENT (Push)  │           │ SENT (Email) │           │ SENT (SMS)   │
            └──────────────┘           └──────────────┘           └──────────────┘
                    │                          │                          │
          ┌─────────┼─────────┐      ┌─────────┼─────────┐      ┌─────────┴─────────┐
          ▼         ▼         ▼      ▼         ▼         ▼      ▼                   ▼
      DELIVERED  FAILED   EXPIRED  BOUNCED  DELIVERED  OPENED  DELIVERED        FAILED

State Storage Requirements:

1. In-Flight Notifications — Track notifications currently being processed. Redis or similar for sub-millisecond lookups.

2. Delivery Attempts — Log each attempt per channel with timestamps and outcomes. Enables retry logic and debugging.

3. Acknowledgment State — Track which notifications user has seen/interacted with. Synced across devices.

4. Notification History — Long-term storage for analytics, compliance, and user-facing notification center.

Delivery failures are inevitable. Devices go offline, email servers reject messages, SMS carriers experience outages. Robust routing includes sophisticated retry and fallback mechanisms.

Retry Strategy:

class RetryPolicy:
    def __init__(self, channel: str):
        self.configs = {
            'push': RetryConfig(
                max_attempts=3,
                initial_delay=1,  # seconds
                max_delay=60,
                backoff_multiplier=2,
                jitter=True
            ),
            'email': RetryConfig(
                max_attempts=5,
                initial_delay=30,
                max_delay=3600,
                backoff_multiplier=2,
                jitter=True
            ),
            'sms': RetryConfig(
                max_attempts=3,
                initial_delay=10,
                max_delay=300,
                backoff_multiplier=2,
                jitter=True
            ),
        }
        self.config = self.configs.get(channel)
    
    def should_retry(self, attempt: int, error: Error) -> bool:
        if attempt >= self.config.max_attempts:
            return False
        
        # Don't retry permanent failures
        if error.is_permanent():
            return False
        
        return True
    
    def get_delay(self, attempt: int) -> float:
        delay = min(
            self.config.initial_delay * (self.config.backoff_multiplier ** attempt),
            self.config.max_delay
        )
        
        if self.config.jitter:
            delay *= random.uniform(0.5, 1.5)
        
        return delay

Distinguishing Error Types:

• Transient — Rate limited, temporary network issue, provider overloaded → Retry with backoff
• Permanent — Invalid token, user unsubscribed, address doesn't exist → Don't retry, update user state
• Unknown — Provider timeout, ambiguous response → Retry cautiously, check delivery status later

Notification routing is the intelligent core of the notification system. It transforms raw events into targeted, prioritized, channel-specific deliveries while handling the complexities of scale, failures, and user preferences.

What's Next:

With routing covered, we'll address a critical user experience challenge: notification overload. The next page explores Batching and Deduplication—techniques for grouping similar notifications, preventing duplicates, and respecting user attention while maintaining deliverability.