Notification systems are the connective tissue of every modern application. They are the primary mechanism through which products re-engage users, communicate time-sensitive information, and drive daily active usage. Without notifications, most mobile applications would see their engagement metrics collapse — studies consistently show that users who enable push notifications retain at rates two to three times higher than those who do not.

At FAANG scale, notification systems operate at staggering volumes. Facebook sends over one billion push notifications per day. Google delivers billions of notifications across Gmail, YouTube, and Android system alerts. Amazon sends hundreds of millions of order updates, delivery alerts, and promotional emails daily. These are not simple fire-and-forget messages — each notification must be personalized, deduplicated, delivered through the correct channel, and respectful of user preferences and quiet hours.

The four primary notification channels each have fundamentally different characteristics. Push notifications (via Apple Push Notification service and Firebase Cloud Messaging) offer near-instant delivery to mobile devices but are limited in content length and require device tokens. Email provides rich formatting, attachments, and permanence but has variable delivery times and spam filtering risks. SMS offers near-universal reach and high open rates (98% within 3 minutes) but is expensive and heavily regulated. In-app notifications are free and fully controlled but only reach users who are actively using the application.

Understanding these scale numbers is critical because they drive every architectural decision downstream. A notification system for a startup with 10,000 users can run on a single server with direct API calls to SendGrid and Firebase. At 100 million notifications per day, you need distributed queues, channel-specific adapters with independent scaling, retry mechanisms with exponential backoff, and sophisticated deduplication to prevent users from receiving the same notification twice.

Before drawing any architecture diagrams, a strong system design answer begins with clarifying requirements. For a notification system, the functional requirements define what types of notifications the system supports and how users interact with them, while non-functional requirements define the reliability, latency, and scale targets that drive the architecture.

A critical question to ask the interviewer: should the notification system support batching and digest mode? If yes, the architecture needs a scheduler component that accumulates events over a time window (e.g., 1 hour) and consolidates them into a single digest notification. This fundamentally changes the pipeline from a real-time streaming model to a hybrid streaming-plus-batch model.

The high-level architecture of a notification system follows a classic event-driven pipeline pattern: event producers emit notification triggers, a central notification service validates and enriches them, channel-specific adapters format and deliver messages through external providers, and a feedback loop tracks delivery status. This pipeline must handle millions of notifications per day while maintaining strict ordering guarantees for per-user notification sequences.

graph TB
    subgraph "Event Producers"
        OP["Order Service"] --> MQ["Message Queue<br/>(Kafka)"]
        SP["Social Service"] --> MQ
        SEC["Security Service"] --> MQ
        MKT["Marketing Service"] --> MQ
        SYS["System Alerts"] --> MQ
    end

    subgraph "Notification Service"
        MQ --> VAL["Validator &<br/>Deduplicator"]
        VAL --> PREF["Preference<br/>Checker"]
        PREF --> RL["Rate Limiter"]
        RL --> TMPL["Template<br/>Engine"]
        TMPL --> ROUTER["Channel<br/>Router"]
    end

    subgraph "Priority Queues"
        ROUTER --> PQ1["Critical Queue<br/>(2FA, security)"]
        ROUTER --> PQ2["High Queue<br/>(social, orders)"]
        ROUTER --> PQ3["Normal Queue<br/>(marketing, digests)"]
    end

    subgraph "Channel Adapters"
        PQ1 --> PA["Push Adapter<br/>(APNs / FCM)"]
        PQ1 --> EA["Email Adapter<br/>(SES / SendGrid)"]
        PQ1 --> SA["SMS Adapter<br/>(Twilio)"]
        PQ2 --> PA
        PQ2 --> EA
        PQ2 --> SA
        PQ2 --> IA["In-App Adapter<br/>(WebSocket)"]
        PQ3 --> PA
        PQ3 --> EA
        PQ3 --> IA
    end

    subgraph "Delivery Providers"
        PA --> APNS["Apple APNs"]
        PA --> FCM["Google FCM"]
        EA --> SES["Amazon SES"]
        EA --> SG["SendGrid"]
        SA --> TW["Twilio"]
        IA --> WS["WebSocket<br/>Server"]
    end

    subgraph "Feedback & Analytics"
        APNS --> FB["Delivery<br/>Feedback"]
        FCM --> FB
        SES --> FB
        TW --> FB
        WS --> FB
        FB --> DLQ["Dead Letter<br/>Queue"]
        FB --> METRICS["Metrics &<br/>Dashboards"]
    end

    style VAL fill:#3b82f6,stroke:#333,color:#fff
    style ROUTER fill:#f59e0b,stroke:#333,color:#fff
    style DLQ fill:#ef4444,stroke:#333,color:#fff
    style METRICS fill:#10b981,stroke:#333,color:#fff

The notification service is the central orchestration layer. It receives raw events from upstream services and transforms them into deliverable notifications. This transformation involves several steps that must execute in sequence: validation (is the event schema correct?), deduplication (have we already processed this event?), preference checking (does the user want this type of notification on this channel?), rate limiting (has the user exceeded their notification budget?), template rendering (generate the final message content), and channel routing (which adapter should deliver this?).

The architecture must support graceful degradation. If the email provider experiences an outage, email notifications should be queued and retried while push and SMS delivery continues unaffected. If the entire notification service is overloaded, the priority queue system ensures that critical notifications (security alerts, 2FA codes) are processed before marketing messages. This layered resilience is what separates a production-grade notification system from a prototype.

Fan-out is the most computationally expensive operation in a notification system. When an event occurs (a celebrity posts a photo, a product goes on sale, a sports match ends), the system must determine every affected user and generate an individual notification for each one. At FAANG scale, a single event can trigger notifications for tens of millions of users simultaneously. The fan-out strategy determines whether this expansion happens eagerly at write time or lazily at read time.

The fan-out problem in notification systems mirrors the classic news feed fan-out problem, but with a critical difference: notifications are push-based (delivered to users) rather than pull-based (fetched by users). This means the system cannot defer work until the user opens the app — the notification must be delivered proactively, often within seconds of the triggering event.

graph TB
    subgraph "Hybrid Fan-Out Decision"
        EVENT["Notification Event"] --> CHECK{"Recipient<br/>Count?"}
        CHECK -->|"< 10K recipients"| FOW["Fan-Out on Write<br/>(pre-compute all)"]
        CHECK -->|"> 100K recipients"| BATCH["Batched Fan-Out<br/>(waves of 50K/min)"]
        CHECK -->|"In-app only"| FOR["Fan-Out on Read<br/>(compute on demand)"]

        FOW --> PQ["Priority Queues"]
        BATCH --> SCHED["Batch Scheduler<br/>(rate-controlled)"]
        SCHED --> PQ
        FOR --> CACHE["Event Cache<br/>(read at query time)"]
    end

    style CHECK fill:#f59e0b,stroke:#333,color:#fff
    style FOW fill:#10b981,stroke:#333,color:#fff
    style BATCH fill:#3b82f6,stroke:#333,color:#fff
    style FOR fill:#8b5cf6,stroke:#333,color:#fff

Pre-computing recipient lists is a key optimization for fan-out on write. Rather than querying the follower graph at notification time (which adds latency and database load), maintain a pre-computed recipient list for each notification source. When a user follows or unfollows someone, update the recipient list asynchronously. This trades storage (maintaining the lists) for write-path latency (instant lookup instead of graph traversal).

Channel adapters are the bridge between the notification system and external delivery providers. Each adapter is a specialized microservice that understands the API, content format, rate limits, and error semantics of its delivery provider. The adapter pattern ensures that the core notification service is decoupled from provider-specific logic — you can swap SendGrid for Mailgun or Twilio for Vonage without changing the core pipeline.

Each channel has fundamentally different delivery characteristics. Push notifications travel through proprietary gateways (APNs for iOS, FCM for Android) that maintain persistent connections to devices. Email flows through SMTP relay chains with store-and-forward semantics. SMS routes through carrier networks with per-country regulations and number formatting rules. In-app notifications use WebSocket connections to deliver messages to users who are currently online.

Delivery guarantees are the most technically challenging aspect of a notification system. Users expect that every important notification reaches them exactly once — they do not want to miss a 2FA code, and they do not want to receive the same order confirmation three times. Achieving this in a distributed system with multiple failure modes (network partitions, consumer crashes, provider timeouts) requires careful engineering of idempotency, deduplication, and retry mechanisms.

The three standard delivery guarantee levels in distributed systems are: at-most-once (fire and forget — fast but may lose messages), at-least-once (retry until acknowledged — no message loss but may duplicate), and exactly-once (each message processed precisely once — the gold standard but expensive to achieve). For notification systems, at-least-once delivery combined with idempotency-based deduplication provides effectively-exactly-once semantics at a practical cost.

Retry strategies must be channel-aware. Push notification retries should be aggressive (1s, 2s, 4s) because APNs and FCM are generally fast. Email retries should be more patient (1min, 5min, 15min, 1hr) because SMTP delivery can be legitimately slow. SMS retries should respect carrier rate limits — retrying too aggressively can trigger carrier throttling or blocking. Each channel adapter manages its own retry policy independently.

User preferences and rate limiting are what separate a notification system that users love from one that they disable entirely. The technical infrastructure for delivering millions of notifications is meaningless if users opt out because they feel spammed. Preference management and rate limiting are not afterthoughts — they are core architectural components that must be designed into the notification pipeline from the start.

User preference data must be accessible on every notification's hot path: the notification service checks preferences before rendering templates or enqueuing delivery tasks. This means preference lookups must be extremely fast (sub-millisecond) and highly available. A preference store failure should fail-closed (suppress the notification) rather than fail-open (deliver unwanted notifications), because a missed notification is recoverable but a user disabling all notifications is often permanent.

The template engine is the component that transforms a raw notification event (event_type, recipient_id, template_params) into a fully rendered, channel-specific message ready for delivery. This involves selecting the correct template, injecting personalized data, localizing the content for the recipient's language and locale, selecting the appropriate A/B test variant, and formatting the output for the target channel (HTML for email, JSON for push, plain text for SMS).

Template rendering sits on the critical path of every notification, so it must be fast (< 5ms per render), cacheable (compiled templates), and fault-tolerant (a missing template parameter should produce a degraded message, not a crash). At FAANG scale, the template engine renders millions of notifications per hour across thousands of template variants.

graph LR
    subgraph "Template Rendering Pipeline"
        EVENT["Notification Event<br/>(template_id, params,<br/>recipient_id)"] --> LOOKUP["Template<br/>Lookup"]
        LOOKUP --> LOCALE["Locale<br/>Resolution<br/>(user lang + region)"]
        LOCALE --> AB["A/B Variant<br/>Selection<br/>(experiment cohort)"]
        AB --> RENDER["Template<br/>Rendering<br/>(Handlebars/Mustache)"]
        RENDER --> FORMAT{"Channel<br/>Format?"}
        FORMAT -->|"Push"| PUSH_FMT["JSON Payload<br/>(title, body,<br/>deep_link, badge)"]
        FORMAT -->|"Email"| EMAIL_FMT["HTML + Plain Text<br/>(inline CSS,<br/>unsubscribe link)"]
        FORMAT -->|"SMS"| SMS_FMT["Plain Text<br/>(160 char limit,<br/>short URL)"]
        FORMAT -->|"In-App"| INAPP_FMT["Structured JSON<br/>(title, body, icon,<br/>action_url)"]
    end

    style RENDER fill:#3b82f6,stroke:#333,color:#fff
    style FORMAT fill:#f59e0b,stroke:#333,color:#fff

Dynamic content injection allows notifications to include real-time data beyond simple template parameters. For example, an email notification for a flight delay might include current weather at the destination, alternative flight options, and a map showing the current aircraft location. This requires the template engine to call external data services during rendering — which adds latency and failure risk. Use a timeout-with-fallback pattern: attempt to fetch dynamic data with a 500ms timeout; if it fails, render without the dynamic section.

Scaling a notification system requires careful attention to partitioning strategies, queue management, priority isolation, and failure handling. The notification pipeline has multiple stages (ingestion, processing, delivery), each with different scaling characteristics and bottleneck patterns. A failure in any stage must be contained and not cascade to other stages or other users.

The most common scaling pattern is horizontal partitioning by user ID. Kafka topics are partitioned by recipient_id, ensuring that all notifications for a given user are processed by the same consumer (enabling per-user deduplication and rate limiting). Channel adapters scale independently based on provider throughput limits. The notification service scales based on event ingestion rate.

graph TB
    subgraph "Scaling Architecture"
        KAFKA["Kafka Cluster<br/>(128 partitions)"] --> CG1["Consumer Group 1<br/>Notification Service<br/>(20 instances)"]
        CG1 --> PQ_C["Critical Topic<br/>(32 partitions)"]
        CG1 --> PQ_H["High Topic<br/>(64 partitions)"]
        CG1 --> PQ_N["Normal Topic<br/>(128 partitions)"]

        PQ_C --> PUSH_C["Push Adapter Pool<br/>(10 instances)<br/>p99 < 100ms"]
        PQ_C --> EMAIL_C["Email Adapter Pool<br/>(5 instances)<br/>p99 < 500ms"]
        PQ_H --> PUSH_H["Push Adapter Pool<br/>(50 instances)"]
        PQ_H --> EMAIL_H["Email Adapter Pool<br/>(20 instances)"]
        PQ_N --> PUSH_N["Push Adapter Pool<br/>(20 instances)"]
        PQ_N --> EMAIL_N["Email Adapter Pool<br/>(30 instances)"]
        PQ_N --> DLQ["Dead Letter Queue"]
    end

    subgraph "Monitoring"
        PUSH_C --> MON["Metrics Pipeline<br/>(Prometheus + Grafana)"]
        EMAIL_C --> MON
        DLQ --> ALERT["PagerDuty Alert<br/>(critical in DLQ)"]
    end

    style PQ_C fill:#ef4444,stroke:#333,color:#fff
    style PQ_H fill:#f59e0b,stroke:#333,color:#fff
    style PQ_N fill:#3b82f6,stroke:#333,color:#fff
    style DLQ fill:#ef4444,stroke:#333,color:#fff
    style ALERT fill:#ef4444,stroke:#333,color:#fff

Dead letter queue management is critical for long-term system health. Build an automated DLQ processor that categorizes failures: invalid device tokens (prune from the token store), permanently bounced email addresses (add to suppression list), expired content (discard — a 3-day-old flash sale notification is worthless), and provider errors (schedule for retry during the next low-traffic window). Alert on the DLQ growth rate, not just the absolute depth — a steady growth rate indicates a systemic issue rather than a transient spike.