How Web Push Notifications Work Internally: Implementing with React + Golang

I understand how browser push infrastructure works and designed it properly.
Push notifications have become a core part of modern applications.
Whenever you receive:

• a new message alert
• an order status update
• a deployment notification
• a payment reminder there is usually a notification system working behind the scenes.

At first glance, sending a notification looks simple:

Backend sends message → User receives notification

But internally, it involves multiple systems working together:

• Browser APIs
• Service Workers
• Push Services
• Encryption
• Authentication
• Backend workers

In this blog, we will understand how Web Push Notifications work internally and implement a complete push notification system using React.js and Golang.

What are Web Push Notifications?

Web Push allows servers to send messages to browsers even when the website is not open.

The browser displays notifications using a background process called a Service Worker.

Backend → Push Service → Browser → Service Worker → Notification

The important idea: Your backend never directly communicates with the browser.

Instead, every browser provides a Push Service that acts as a delivery system. for example; Chrome: Google Firebase Cloud Messaging, Firefox: Mozilla Push Service

High Level Architecture

Our system contains five major components.

Subscription Flow:

React Application → Service Worker Registration → Push Subscription → Golang Backend → Database

Notification Delivery Flow:

Golang Backend → Browser Push Service → Service Worker → User Notification

Generating VAPID Keys

Before creating subscriptions, our application needs public/private keys.

Generate them using:

package main

import (
    "fmt"
    webpush "github.com/SherClockHolmes/webpush-go"
)

func main(){
    privateKey, publicKey, _ := webpush.GenerateVAPIDKeys()
    fmt.Println("Public:",publicKey)
    fmt.Println("Private:",privateKey)
}

The generated keys:

Public Key:

• sent to React application
• used while subscribing

Private Key:

• stored securely in backend environment variables
• used while sending notifications

React Application

The frontend handles:

• requesting notification permission
• registering service worker
• generating push subscription
• sending subscription details to backend

Service Worker

A Service Worker is a JavaScript file that runs separately from your React application.
It works even when:

• tab is closed
• application is inactive
• browser is running in background

Responsibilities:

• listen for push events
• display notifications
• handle notification clicks

Browser Push Service

This is managed by browsers.

• maintain device connections
• receive push messages
• wake service workers

Golang Backend

Backend responsibilities:

• store subscriptions
• authenticate push requests
• encrypt notification payloads
• send notifications

Subscription Flow

Before sending notifications, the browser needs to register itself.

User Opens Website → Allow Notification Permission → Register Service Worker → Generate Push Subscription → Send Subscription To Backend → Store In Database

React Implementation

First, check browser support.

if ( "serviceWorker" in navigator && "PushManager" in window ) { console.log("Push supported"); }

Request Notification Permission

Browsers require user approval.

async function requestPermission() {
   const permission = await Notification.requestPermission();
   if(permission !== "granted"){
      return;
   }
   console.log( "Notifications enabled" );
}

Register Service Worker

React cannot listen for background events. We register a worker:

const registration = await navigator.serviceWorker.register("/worker.js" );
console.log( "Worker registered", registration );

Creating Push Subscription

Now we create a browser subscription.

const subscription = await registration.pushManager.subscribe({ userVisibleOnly:true, applicationServerKey: VAPID_PUBLIC_KEY });
await fetch( "/api/subscriptions", { method:"POST", body: JSON.stringify(subscription) });

The generated subscription contains:

{ "endpoint":"https://push-service.com/xxx", "keys":{ "p256dh":"public-key", "auth":"secret-key" } }

This is the browser address where notifications will be delivered.

Understanding Service Worker

Create: public/worker.js
A Service Worker listens for push events.

self.addEventListener( "push", event => { 
    const data = event.data.json();
    event.waitUntil(self.registration.showNotification(data.title, 
    { body:data.message, icon:"/icon.png" }));
});

Important: The notification is created outside React. React does not even need to be running.

Sending Notifications Using Go

For implementing Web Push Protocol in Golang, we use:

go get github.com/SherClockHolmes/webpush-go

Import the package:

import (
    webpush "github.com/SherClockHolmes/webpush-go"
)

This package handles:

• payload encryption
• VAPID authentication
• communication with browser push services

Example implementation:

func SendNotification(subscription Subscription, message string) error { 
    _,err := webpush.SendNotification([]byte(message), 
        &webpush.Subscription{Endpoint: subscription.Endpoint,
            Keys:webpush.Keys{Auth: subscription.AuthKey, P256dh: subscription.P256dhKey}},
        &webpush.Options{VAPIDPublicKey: PUBLIC_KEY, VAPIDPrivateKey: PRIVATE_KEY}) 
    return err
}

The Go server:

• Reads subscription from database
• Encrypts the payload
• Signs request using VAPID
• Sends message to browser push service

Understanding VAPID Authentication

VAPID stands for: Voluntary Application Server Identification
It proves that:

This notification came from an authorized backend.

It uses two keys:
Public Key : Shared with Browser
Private Key : Stored only on Backend
Never expose VAPID_PRIVATE_KEY in frontend code.

Production Challenges

A demo notification system is easy. A production notification system requires handling edge cases.

Multiple Devices

A single user may have: Chrome Desktop, Android Device, Firefox
Each browser creates a different subscription.

Bad design: One user = One subscription

Better: One user = Many subscriptions

Expired Subscriptions

Push subscriptions can expire.
Reasons:

• browser reset
• permission removed
• device change Push services return: 404 or 410

Remove invalid subscriptions.

Scaling Notification Delivery

Sending notifications directly from APIs works for small systems.
But imagine: 1 Million users
Better architecture:

Application Event → Kafka → Notification Workers → Browser Push Services → Users

Benefits:

• asynchronous processing
• retries
• better reliability
• horizontal scaling

Retry Handling

Failures happen because of:

• network errors
• push service issues
• temporary outages

A production system should have:

• retry queues
• exponential backoff
• dead letter queues

Example:

Notification Failed → Retry Queue → Try Again → Dead Letter Queue

Why not WebSockets?

WebSockets are great when users are actively using the application.

Examples:

• live chats
• multiplayer games
• collaborative editing

But WebSockets require an active connection.

When:

• the browser tab is closed
• device is locked
• application process stops

your React application cannot receive messages.
Web Push solves this using Service Workers that can wake up independently from the application.

Security Notes

A few things to remember:

• Always use HTTPS in production
• Never expose VAPID private keys
• Validate users before storing subscriptions
• Remove expired subscriptions
• Avoid sending sensitive information directly inside notification payloads

Comments

[Nazar Boyko]

In that Go SendNotification wrapper, the _, err := is going to quietly defeat your own cleanup advice. webpush-go hands back the *http.Response, and a 410 Gone or 404 comes through as a successful call carrying that status code, not as a Go error. So return err stays nil on a dead subscription, and the prune step you describe later never has anything to fire on. Capture the response, check resp.StatusCode, and delete on 404 or 410. Small change, but it's the difference between the expired subscription handling actually working and only looking like it does.