A notification system delivers messages to users through multiple channels — push notifications, SMS, email, and in-app alerts. It seems simple: something happens, tell the user. But at scale, you are coordinating millions of messages per hour across unreliable third-party providers (APNs, FCM, Twilio, SendGrid), each with different delivery semantics, rate limits, and failure modes. The challenge is not sending one notification — it is sending the right notification, to the right user, through the right channel, exactly once, within seconds.

Notification systems vary enormously by use case. A ride-hailing app sending "your driver is arriving" has completely different requirements than a social network sending "someone liked your post." The questions below determine whether you need a real-time pipeline or a batch system, strict delivery or best-effort, and how much complexity the preference layer adds.

The simplest design: when an event occurs (user gets a new message), the application server directly calls the notification providers — APNs, SendGrid, Twilio — in the same request path. Send the push, send the email, respond to the caller. Works great for a prototype. At scale, a single slow provider (Twilio having a bad day) blocks your entire application and creates cascading failures across unrelated features.

The refined design decouples notification creation from delivery. A caller publishes a notification event to a message queue and returns immediately. Dedicated workers per channel consume from their queues, apply user preferences, deduplicate, and deliver through the appropriate provider. Failed sends go to a retry queue with exponential backoff. This architecture isolates provider failures, enables independent scaling per channel, and never blocks the application. For events that require all channels simultaneously — such as a security alert — the notification service fans out to multiple queues in parallel rather than sequentially, ensuring push, email, and SMS are dispatched at the same time.

The two dominant architectural choices differ in how you organize the message pipeline. A single unified queue is simpler to operate but creates coupling between channels. Per-channel queues add operational overhead but provide isolation, independent scaling, and channel-specific optimization. The right choice depends on scale and operational maturity.

Every major platform has built a notification system — and every one has learned the hard way about duplicate sends, provider outages, and user notification fatigue. Their approaches differ, but common patterns emerge: event-driven architectures, separate processing per channel, and preference engines that sit between event generation and delivery.

Notification systems teach patterns that apply to any system involving multi-channel delivery, user-facing reliability, and asynchronous processing. These are not notification-specific — they are principles of reliable event-driven architectures.

Notification failures are uniquely visible to users — a missed password reset email or a duplicate charge notification erodes trust immediately. The failures below are not theoretical: every major platform has experienced them, and the fixes are well-established patterns that separate production-grade systems from prototypes.