Push notifications vs in-app live updates
Reaching users when the app is closed.
A WebSocket only works while the app is open and connected. When the delivery driver arrives and the customer's phone is in a pocket with the app closed, there is no connection to push through. Mobile operating systems also stop background apps from holding connections for long, to save battery. Reaching a closed app uses a different path: a push notification, delivered through the platform's own service (Apple's APNs for iOS, Firebase Cloud Messaging for Android), which the OS keeps one shared connection to.
So most products use both. If the user has a live connection, deliver in-app, update the screen and skip the notification. If not, send a push notification with a short summary, and when they tap it the app opens, reconnects and syncs the full data. The notification is a nudge; the real content still comes from your servers. This is the same lesson as recovery: the log is the truth.
Choosing the path for each event
Step 1 of 4
Check presence
The router asks whether the user has an active connection on any device. Presence lookups should be cheap and approximate, as discussed earlier.
Push notifications are best effort. The platform may delay or drop them, devices may be offline, and tokens expire when users reinstall. Never rely on a notification as the only way to learn something important; it should always be backed by data fetched on app open. Payloads are small (a few kilobytes) and pass through third parties, so avoid sensitive details in the text.
Your turn
Design the rules for notifying a user about new chat messages: when do you skip the push, when do you batch, and what do you include?
Stuck? Use presence and frequency.
What to remember
WebSockets serve connected apps; push services reach closed apps.
Route by presence: live update if connected, push notification if not.
Notifications are best effort, so the server remains the source of truth.
Batch, collapse and respect settings to avoid notification fatigue.