Push Notification Architecture

Build the mental model

A push notification is triggered from outside the device: your backend, or a third-party service acting for it, decides that something happened -- a new chat message, a comment, a completed payment -- and delivers that information to the device even while the app is closed or the phone is asleep.

A local notification, by contrast, is scheduled entirely by the app itself, on the device, with no server involved at all: a study reminder at 8 PM, a workout timer finishing, a habit-tracking nudge the app set hours earlier.

To notify that user later, the backend does not contact the device directly -- it hands the token and a payload to a push service, delivery infrastructure the platform itself operates, which routes the message to the right device and surfaces it as a system notification or passes it straight to the running app.

A payload usually carries a title, a body, optional custom data such as an id used for a deep link, and delivery metadata.

React Native's own push-notification lesson covers framework-specific registration code; this lesson covers the architecture underneath any framework's implementation of it.

Push Notification

A message triggered by a server or service and delivered to a device through the platform's push infrastructure, even while the app is closed.

Device Token

A unique identifier a platform issues to one app installation on one device, used by a backend to target that install through the push service.

PUSH NOTIFICATION FLOW
----------------------
PUSH NOTIFICATION FLOW
-----------------------
DEVICE TOKEN REGISTRATION
  Mobile App --> Register for Notifications
  Mobile App --> Receive Device Token
  Mobile App --> Send Token to Backend
  Backend    --> Stores Token (per user, per device)

SENDING A PUSH
  Backend --> Push Service --> Device --> Mobile App / Notif.
  (event happens)  (platform delivery)    (shown to the user)

LOCAL NOTIFICATION (no backend involved)
  Mobile App --> Schedules Locally --> OS Delivers at Set Time

Connect it to a real scenario

Think through the full loop before writing any code. The app should ask for notification permission with context -- explaining why, ideally right before the moment it matters -- not as a blind prompt on first launch.

Once granted, the platform hands the app a device token, and the app's only job is to send that token to your backend right away, and again whenever it changes, since tokens can rotate after a reinstall or an OS update.

• Backend owns a table mapping user accounts to device tokens -- typically several tokens per user.
• When a notify-worthy event happens, the backend builds a payload and sends it to the push service per token.
• Keep the payload's data field small -- usually just a type and an id to route a tap to the right screen.
• Keep visible title/body generic for anything sensitive; fetch real detail after the user opens and authenticates.

• Push notifications come from a server or service; local notifications are scheduled entirely on-device with no server involved.
• A device token is the unique address the backend uses to target a specific app install through the platform's push service.
• Notification payload content is effectively public once it can render on a lock screen -- never put sensitive details in it directly.

Try the working example

function evaluateNotificationPayload(payload, context) {
  if (!payload.containsSensitiveInfo) {
    return { verdict: "safe", action: "show-as-is", reason: "No sensitive info in the payload." };
  }
  if (context.isLockScreen) {
    return {
      verdict: "unsafe",
      action: "redact",
      reason: "Sensitive info would render on the lock screen for anyone to see."
    };
  }
  return {
    verdict: "risky",
    action: "redact-recommended",
    reason: "Content also persists in the notification center after unlock, so redact by default."
  };
}

const orderUpdate = {
  title: "Order shipped",
  body: "Your order is on its way!",
  containsSensitiveInfo: false
};

const labResult = {
  title: "New result from Dr. Lin",
  body: "Your test came back positive for...",
  containsSensitiveInfo: true
};

console.log("Order update:", evaluateNotificationPayload(orderUpdate, { isLockScreen: true }));
console.log("Lab result:", evaluateNotificationPayload(labResult, { isLockScreen: true }));

The safe order-shipped notification returns { verdict: 'safe', action: 'show-as-is' } since it has no sensitive info. The lab-result notification returns { verdict: 'unsafe', action: 'redact', reason: 'Sensitive info would render on the lock screen for anyone to see.' } because it contains sensitive info and the context is a lock screen.

Push technology - Wikipedia — How Mobile Apps Work