Just studied how push notifications work - correct me if I’m wrong anywhere

[Pillai]

There are basically three types of notifications:

* SMS
* Email
* Push notifications (from apps)

Different providers handle them:

* Email → Mailchimp, ActiveCampaign, etc.
* SMS → Twilio, Sinch, etc.
* Push notifications → Firebase Cloud Messaging (FCM)

When you install an app and grant notification permission, Firebase creates an FCM/device token for that device. The app sends this token to the backend and stores it in the database.

Later, whenever the backend wants to push a notification, it calls Firebase with that token and Firebase knows which device to deliver to.

I was wondering how notifications still arrive when the app is closed.

Turns out Android relies on Google Play Services running in the background, which keeps a connection with Firebase Cloud Messaging. So even if the app is killed, the OS/Play Services can still receive and show the notification.

Also, the token may change sometimes, for example after uninstalling and reinstalling the app.

A typical flow looks like:

Services → Authentication → Message Queue → Worker → Firebase → User

[Sonal]

FCM isn't the only push service out there. Apple uses APNs (Apple Push Notification service) for iOS, and most production apps don't talk to FCM or APNs directly. They go through an intermediary like OneSignal, Novu, or even AWS SNS, which hides the differences between FCM and APNs. That saves a lot of headache when you target both platforms.

About the token – it can change not only on reinstall. FCM may rotate the token if the user clears app data, switches devices, or sometimes just randomly. That's why many apps silently refresh and re‑sync the token to the backend on every launch, not just at install time.

The "app closed but notifications still work" part is the most interesting. On iOS there's no persistent socket like Play Services. APNs maintains its own connection at the OS level, so the app is even more out of the picture than on Android.

One more layer you didn't mention: there are silent/data notifications (no UI shown) used to trigger background syncs or invalidate caches. Sneaky but super useful.

Good write‑up, most people don't dig into this stuff under the hood.

[Krishna]

It's basically just a publisher‑subscriber model.

[Mohit]

There are a lot of moving parts. It looks simple on the surface but underneath you need to handle many things:

* Token refresh handling
* Body vs data payload structures
* Priority settings
* Metrics (clicks, deliveries, etc.)
* Call‑to‑action handling
* CTA when the app is closed
* And many more

To simplify, tools like Novu, OneSignal do the heavy lifting, and CleverTap is popular for marketing push notifications.

Using them in production still requires solid knowledge and hands‑on experience. I've been managing all these at my current company.

[Bhavana]

There's also in‑app notifications – the ones you see while you're actively using the app.

[Shivam]

What happens when you log out or uninstall the app? When logging out, do you clean up the user's data in your database, or do you keep an async job to handle the cleanup later?

[Sunita]

If you don't want to spend time figuring out how it works, just use Nuvix (https://github.com/nuvix-dev/nuvix/). It handles messaging out of the box – SMS, email, or push notifications – and you can send everything via a simple API or SDK without dealing with unnecessary complexity.