Web Push Technical Architecture: Deep Dive into Service Workers, VAPID Keys & Push Services

For software engineers, DevOps architects, and technical team leads, understanding how web push notifications function under the hood is vital for building reliable, high-performance, and secure customer communication infrastructure. Unlike WebSockets or Server-Sent Events (SSE) that require an active, open browser tab, web push operates via background Service Workers managed by the operating system and browser push servers.

In this technical deep-dive, we explore the three-party architecture powering web push notifications: your backend application server, the browser push service (Google FCM, Apple APNs, Mozilla Autopush), and the client-side Service Worker.

---

The 3 Core Components of Web Push Architecture

1. Client Browser & Service Worker: A background JavaScript worker running on a separate thread from web pages, capable of receiving network push events even when the site is closed.
2. Push Service Provider (FCM, APNs, Mozilla): Maintained by browser vendors to manage device connection states and queue push messages for offline devices.
3. Application Server (Backend): Creates cryptographic payload signatures using VAPID (Voluntary Application Server Identification) keys and dispatches HTTP/2 requests to push service endpoints.

---

Understanding VAPID Authentication (RFC 8292)

VAPID replaces the need for proprietary API tokens by using asymmetric public key cryptography (ECDSA on curve NIST P-256). When your backend transmits a push message, it signs a JWT token with your Private Key, allowing push services like Google FCM and Apple APNs to verify that the message originated from the authorized application owner without storing secret credentials.

// Example: Node.js VAPID Push Dispatching
const webpush = require('web-push');

webpush.setVapidDetails(
  'mailto:admin@lumapush.com',
  process.env.VAPID_PUBLIC_KEY,
  process.env.VAPID_PRIVATE_KEY
);

const pushSubscription = {
  endpoint: 'https://fcm.googleapis.com/fcm/send/xyz123...',
  keys: {
    auth: 'authKey123...',
    p256dh: 'p256dhKey123...'
  }
};

const payload = JSON.stringify({
  title: '🚀 New Feature Released',
  body: 'Check out the new automation studio in your dashboard.',
  icon: '/logo.png',
  url: 'https://lumapush.com/features'
});

webpush.sendNotification(pushSubscription, payload)
  .then(res => console.log('Delivered successfully:', res.statusCode))
  .catch(err => console.error('Delivery failed:', err));

Learn how Apple integrates APNs with VAPID in our Safari iOS Web Push Guide and see how to transfer VAPID keys in our OneSignal Migration Guide.

---

Payload Encryption: RFC 8291 Mechanics

Web push security requires strict end-to-end encryption. Before a payload leaves your application server, it is encrypted using the recipient's p256dh public key and auth secret with AES-128-GCM encryption. Even though the message passes through Google, Apple, or Mozilla push servers, the vendor cannot read or inspect your message contents.

---

Service Worker Event Handlers: Listening to Push & Clicks

Inside the client service-worker.js file, two primary event listeners manage incoming notifications:

// Service Worker: push and notificationclick listeners
self.addEventListener('push', (event) => {
  const data = event.data ? event.data.json() : {};
  const title = data.title || 'Notification';
  const options = {
    body: data.body,
    icon: data.icon || '/icon.png',
    image: data.image,
    data: { url: data.url || '/' },
    actions: data.actions || []
  };

  event.waitUntil(self.registration.showNotification(title, options));
});

self.addEventListener('notificationclick', (event) => {
  event.notification.close();
  const targetUrl = event.notification.data.url;
  event.waitUntil(clients.openWindow(targetUrl));
});

---

Time-To-Live (TTL) & Urgent Delivery Prioritization

Push service gateways allow senders to configure HTTP/2 request headers that dictate how delivery is prioritized:

• TTL (Time-To-Live): Specifies the number of seconds (e.g., 86,400 for 24 hours) the push server will retain the message if the client device is offline.
• Urgency: Values like high, normal, or very-low indicate to operating systems whether to immediately wake radio sockets or conserve battery.
• Topic / Collapse Key: Replaces pending outdated notifications with newer alerts on the same topic.

---

---

Cryptographic Deep Dive: ECDSA NIST P-256 Key Exchange

The security of the W3C Web Push protocol relies on Elliptic Curve Cryptography. When your application server identifies itself to Google FCM, Apple APNs, or Mozilla Push Service via VAPID (Voluntary Application Server Identification), it generates an asymmetric keypair on the NIST P-256 (prime256v1) curve:

• Public Key (Uncompressed P-256 Point): A 65-byte coordinate point prefixed with 0x04, converted to Base64URL encoding. This key is embedded in client-side scripts.
• Private Key (Scalar): A 32-byte secret scalar used to compute HMAC-SHA256 digital signatures on outbound JWT authorization headers.
• Subscriber Key (p256dh): Generated uniquely by each subscriber's browser to establish an ECDH shared secret for message payload encryption.
• Auth Secret: A 16-byte random salt used to prevent replay attacks and authenticate encrypted payloads.

---

High-Performance Push Queue Workers with Redis & Node.js

Broadcasting to 1,000,000 subscribers in seconds requires an asynchronous worker queue. Modern push infrastructure utilizes BullMQ or RabbitMQ backed by Redis to distribute payload encryption and HTTP/2 socket dispatches across multiple CPU cores, preventing server bottlenecks.

// High-throughput Push Dispatch Worker in BullMQ
const { Worker } = require('bullmq');
const webpush = require('web-push');

const worker = new Worker('push-dispatch-queue', async (job) => {
  const { subscription, payload } = job.data;
  try {
    const res = await webpush.sendNotification(subscription, JSON.stringify(payload));
    return { success: true, statusCode: res.statusCode };
  } catch (err) {
    if (err.statusCode === 410 || err.statusCode === 404) {
      // Endpoint expired: deactivate subscriber token in database
      await db.subscribers.update({ where: { endpoint: subscription.endpoint }, data: { active: false } });
    }
    throw err;
  }
}, { concurrency: 50 });

---

Handling Stale Tokens and HTTP 410 Pruning

When subscribers clear browser cookies, uninstall browsers, or revoke notifications in OS settings, the push gateway returns an HTTP 410 Gone or HTTP 404 Not Found status code. LumaPush automatically prunes expired endpoints from your active broadcast database, maintaining 99.8% list hygiene and preventing wasted server compute cycles.

---

End-to-End Payload Encryption (RFC 8291 & RFC 8188)

Web Push payloads are never transmitted in cleartext over the internet. RFC 8291 (Message Encryption for Web Push) mandates that all JSON payloads be encrypted with AES-128-GCM using content encryption keys derived from the subscriber's public key and the server's ephemeral Diffie-Hellman exchange. This guarantees that intermediate push gateways (such as Google FCM and Apple APNs) can deliver the notification packet without ever inspecting the private contents inside.

---

Frequently Asked Questions (FAQ)

What happens if a user is offline when a push notification is sent?

Browser push services use a Time-To-Live (TTL) parameter. If a subscriber's device is turned off or offline, the push service queues the message and delivers it the moment the device reconnects to the internet.

Can push notification payloads be intercepted?

No. The W3C Web Push standard mandates end-to-end payload encryption using RFC 8291 (Message Encryption for Web Push). Payloads are encrypted with the client's public key before leaving your server, ensuring push services cannot inspect message contents.

What cryptographic curve does VAPID use?

VAPID relies on the NIST P-256 (prime256v1) elliptic curve algorithm to generate ECDSA public and private keypairs for request authentication.

Why does web push require HTTPS?

Because Service Workers have access to low-level browser caching and background network threads, web security standards require full HTTPS encryption to prevent man-in-the-middle attacks.

What is the maximum payload size for a web push notification?

The W3C Web Push standard defines a maximum payload limit of 4,096 bytes (4 KB), which is plenty for title, body, icon URL, hero image URL, and interactive action button definitions.

How does LumaPush handle millions of push connections simultaneously?

LumaPush utilizes an event-driven HTTP/2 connection pooling architecture that multiplexes thousands of push requests concurrently directly to Google FCM and Apple APNs gateways.

Can Service Workers run when the browser is completely closed?

On Android and Windows, the OS maintains a persistent background socket that wakes the Service Worker on incoming push events even when browser tabs are closed.