How Push Notifications Work: APNs, FCM and Web Push

Push notifications let a server reach a user's device when the app isn't open. Your backend doesn't connect to phones directly: it sends each message to a platform push service, Apple Push Notification service (APNs) for iOS, Firebase Cloud Messaging (FCM) for Android, or a browser vendor's Web Push service, which delivers it over a connection the operating system keeps open. Designing a notification system means managing device tokens, fanning out at scale, respecting preferences, and accepting that delivery is best-effort.

How delivery works

1. The app asks the user for permission and registers with the platform, receiving a device token that identifies this app install on this device.
2. The app sends the token to your backend, which stores it against the user. A user may have many tokens (phone, tablet, browsers).
3. When something happens, the notification service decides whether, what and when to notify, then sends a request to APNs, FCM or a Web Push endpoint with the token and payload.
4. The platform delivers the message when the device is reachable, and the OS shows it or wakes the app.

Delivery is best-effort

• Platform services queue messages for offline devices only for a limited time, and may collapse several pending messages into the latest one.
• Devices in power-saving modes may delay delivery; users may disable notifications entirely.
• There's no reliable delivery receipt for whether the user saw it.
• So never put critical state only in a notification. The app should fetch the source of truth when opened (an inbox, sync on launch). See offline-first sync.

Managing tokens

• Tokens change on reinstall, restore and sometimes periodically; the app must send the current token on every launch.
• When the push service reports a token as invalid or unregistered, delete it immediately, or you'll keep paying to send to dead devices and may be throttled.
• On sign-out, unlink the token from the user so the next person on that device doesn't get their notifications.

Sending at scale

• Queue and fan out: a broadcast to millions of users is split into batches processed by workers from a message queue, with retries and a dead-letter queue.
• Respect provider limits: push services rate-limit senders; use their batch or HTTP/2 multiplexed APIs and back off on throttling.
• Deduplicate: use a notification ID so retries and duplicate events don't buzz the user twice. See idempotency.
• Prioritise: transactional notifications (OTP codes, order updates) go ahead of marketing campaigns in separate queues.
• Track outcomes: sent, accepted by the provider, failed, opened, so you can measure and debug.

Being a good citizen

• Preferences: per-channel and per-category opt-outs, honoured everywhere.
• Quiet hours and time zones: don't send non-urgent notifications at 3 a.m. local time; schedule them.
• Frequency caps and digests: merge many low-value events ("12 people liked your post") instead of sending each.
• Ask for permission in context, after the user understands the value, not on first launch.
• Keep payloads small and non-sensitive: lock screens show them. Send an ID and let the app fetch details securely.