The short answer
Quick answer: Your phone keeps one persistent connection open to its platform's push service: APNs (Apple Push Notification service) on iPhones and FCM (Firebase Cloud Messaging) on Android. When an app is installed, it gets a device token from that service and sends it to the app's backend. To notify you, the backend sends a message and the token to APNs or FCM, which delivers it down that existing connection and wakes the app or shows the alert. At scale, the backend is a pipeline: events go into a queue, workers apply user preferences and rate limits, render the message, and send it through the right channel with retries.
Why apps cannot push directly
If every app kept its own connection to its own server, a phone with 80 apps would hold 80 connections and the battery would be flat by lunchtime. Mobile operating systems also suspend apps in the background.
So the operating system maintains one shared, efficient connection to its vendor's push service, and every app's notifications travel through it. For web browsers, the equivalent is the Push API, which delivers messages to a service worker even when the site is closed.
The delivery path
Registration
- The app asks the user for permission to send notifications.
- The operating system registers with APNs or FCM and receives a device token: an opaque identifier for this app on this device.
- The app sends the token to your backend, which stores it against the user's account.
A user can have several devices, so there may be several tokens. Tokens change: after reinstalling, restoring a backup, or sometimes after an update. The backend must update them and discard old ones.
Sending
- Your server authenticates to the push provider and sends a request containing the token and a payload (title, body, badge count, custom data).
- The provider looks up the device and pushes the message over its connection.
- The device displays the notification or hands the data to the app.
What the provider does and does not promise
- Delivery is best effort. If the device is offline, the provider stores the notification for a limited time and may keep only the most recent one per app.
- Payloads are small, a few kilobytes at most.
- The provider reports invalid tokens (the app was uninstalled). You must stop sending to them.
- Providers throttle senders that misbehave.
Because delivery is not guaranteed, a notification should be a prompt to open the app, not the only copy of important information. The FCM documentation describes message types, priorities and delivery behaviour in detail.
The notification service
A real product sends more than push: also email, SMS and in-app messages. A dedicated notification service handles them all behind one interface.
1. Trigger. Another service publishes an event or calls the API: "order 123 shipped, notify user 42".
2. Enqueue. The request goes into a message queue. The calling service returns at once and is unaffected by slow providers.
3. Decide. A worker picks it up and checks:
- Preferences: has the user opted out of this category or channel?
- Quiet hours and time zone.
- Channel selection: push, email, SMS, or a fallback chain.
- Deduplication: has this exact notification already been sent?
- Frequency caps: has this user had too many today?
4. Render. Fill a template with the user's name, language and details.
5. Fan out. Create one send task per device token and channel.
6. Send. Channel-specific workers call APNs, FCM, an email service or an SMS gateway.
7. Track. Record the outcome: sent, failed, delivered, opened.
Email follows its own long path after this point; see how email works.
Sending millions
A breaking-news alert or a marketing campaign targets millions of devices at once.
- Separate queues by priority. A one-time passcode must not wait behind ten million promotional messages. Use different queues, or at least different priorities, for transactional and bulk traffic.
- Scale workers horizontally. Sending is mostly waiting on the network, so many workers can run in parallel.
- Reuse connections. Keep long-lived HTTP/2 connections to providers and send many requests over each. See why HTTP/2 exists.
- Respect provider limits. Throttle your own sending so you are not rate limited; see how rate limiters work.
- Use topics for broadcasts. Providers let devices subscribe to a topic, so one request reaches all subscribers.
- Spread campaigns over time, partly to protect your own servers: millions of users opening the app in the same minute is a self-inflicted traffic spike.
Reliability
- Retries. Temporary failures are retried with exponential backoff. Permanent failures (bad token, malformed payload) are not.
- Idempotency. Queues deliver at least once, so a worker may see the same task twice. Give each notification a unique ID and record what has been sent, so retries do not produce duplicates. See idempotency.
- Dead-letter queue. Messages that keep failing are set aside for inspection.
- Token hygiene. Remove tokens the provider reports as invalid, or you waste capacity and hurt your sender reputation.
- Expiry. A "your driver is arriving" alert is useless an hour later. Set a time to live so stale notifications are dropped. A collapse key lets a newer notification replace an older undelivered one.
Push versus in-app real time
When the app is open, it often has its own connection to your servers, typically a WebSocket, and updates arrive through that. Push providers are for when the app is closed or in the background. Many systems send through both and let the app suppress the duplicate.
Respecting users
The technical system is only half of a good notification service.
- Ask for permission in context, with a clear reason.
- Offer granular controls by category.
- Cap frequency, and batch low-value updates into a digest.
- Honour quiet hours.
- Do not put sensitive details on the lock screen.
People who feel spammed turn notifications off entirely, or uninstall the app. Restraint keeps the channel useful.
Frequently asked questions
What is a device token?
An identifier issued by Apple's or Google's push service for one app on one device. Your server uses it as the address for sending notifications.
What are APNs and FCM?
APNs is Apple's push service for iOS, macOS and related devices. FCM is Google's service for Android, and it can also relay to APNs and web browsers.
Are push notifications guaranteed to be delivered?
No. They are best effort. Devices may be offline, users may disable them, and providers may drop or collapse messages.
Why do I sometimes get the same notification twice?
Usually a retry without deduplication, or the same alert sent through two channels or to two registrations of the same device.
Conclusion
Push notifications work because every phone keeps a single connection to its platform's push service, and apps address devices by token. Around that sits an ordinary but carefully built pipeline: queue the request, check preferences, render, fan out, send with retries, and clean up dead tokens. The engineering challenge is volume; the product challenge is sending only what people want.
Related articles
- How Message Queues Like Kafka Decouple Systems
- How Rate Limiters Protect APIs From Abuse
- How WebSockets Enable Real-Time Apps Like Chat and Live Scores
- How Email Travels From Your Outbox to Someone's Inbox
Sources and further reading
