System Design for Beginners #18: How Notification Systems Work (Designing Push Notifications at Scale)

Imagine this.

Someone sends you a message on WhatsApp.

Within seconds: your phone vibrates notification appears even if app is closed

Feels simple.

But behind the scenes:

• millions of devices
• multiple platforms
• distributed systems
• retries and queues

Are all working together.

First, Think About Postal Delivery Systems

Imagine sending letters worldwide.

You need:

• sender
• sorting centers
• delivery networks
• destination addresses

Notification systems work similarly.

What Is a Push Notification?

A push notification is:

A message sent from server → user device

Even when app is not actively open.

Examples:

• “Your order arrived”
• “You got a new follower”
• “Flash sale starts now”

High-Level Notification Architecture

Flow:

User Action ↓ Backend generates event ↓ Notification Service ↓ Push Providers ↓ User Device

Simple idea: 👉 events trigger notifications.

Step 1: Event Happens

Example:

User A liked your photo

This creates an event.

Usually handled using:

• message queues
• event-driven architecture

Because notification systems must scale massively.

Step 2: Notification Service Processes It

Notification service decides:

• who should receive it
• notification content
• delivery priority

This service often handles:

• batching
• retries
• throttling
• scheduling

Step 3: Push Notification Providers

Apps cannot directly push to phones themselves.

Instead they use platform services:

Apple Devices

Use:

• Apple Push Notification Service (APNs)

Android Devices

Use:

• Firebase Cloud Messaging (FCM)

These providers handle: ✅ device communication ✅ background delivery ✅ battery optimization

Why Notification Systems Are Hard

Sending one notification is easy.

Sending:

• billions daily
• globally
• instantly
• reliably

Becomes very difficult.

Major Challenges

Massive Scale

Apps like:

• Instagram
• TikTok

Send: 👉 millions of notifications every minute.

System must avoid overload.

Retry Logic

What if:

• phone offline
• network unavailable

System retries later.

Queues are heavily used here.

Spam Prevention

Too many notifications: ❌ users uninstall app

So systems implement:

• rate limiting
• prioritization
• personalization

Real-Time Delivery

Users expect: ⚡ instant delivery

This requires:

• low latency systems
• distributed infrastructure
• event-driven pipelines

Fan-Out Problem (Important)

Suppose celebrity posts something.

Millions of followers need notifications instantly.

This creates:

Fan-Out at Massive Scale

Huge distributed systems challenge.

Notification Types

✅ Push Notifications

Mobile device alerts

✅ In-App Notifications

Inside app only

✅ Email Notifications

Background async delivery

✅ SMS Notifications

Used for critical alerts/OTP

Real Systems Behind Notifications

Large systems often use:

• Apache Kafka
• RabbitMQ
• Redis

To manage:

• queues
• event streaming
• delivery pipelines

Real Engineering Insight

Notification systems are not just:

“sending messages”

They are: ✅ distributed systems ✅ event pipelines ✅ scalable delivery networks ✅ reliability engineering

At massive scale, this becomes incredibly complex.

Important Trade-Off

Too many notifications: ❌ annoying

Too few notifications: ❌ low engagement

So notification systems also become: 👉 behavioral engineering systems.

Key Takeaway

Modern apps feel alive because: 👉 systems constantly react and communicate with users in real time.

Notification systems are one of the biggest engagement engines on the internet.

What You Just Learned

• Push notification architecture
• APNs & FCM basics
• Event-driven notification pipelines
• Retry systems
• Fan-out problems at scale
• Real-time delivery thinking