How to Architect a Real-Time Notification System

Three transport options exist for pushing notifications to the frontend. WebSockets provide full bidirectional communication but require maintaining persistent connections, which consumes server resources at scale. Server-Sent Events are a simpler one-way push mechanism built on HTTP that automatically reconnects and is well-suited for notification delivery where the client does not need to send data back over the same connection. Long polling is the most compatible fallback but is least efficient. Use SSE for notification delivery unless the application already uses WebSockets for other features.

Define a consistent schema for all notification types. Every notification needs a unique ID, the recipient's user ID, a category like mention, comment, or system alert, a title, a body, an optional action URL, a read boolean, a creation timestamp, and the sender identity if applicable. Use a discriminated union type system where the category field narrows the set of additional fields present. This consistency enables generic notification rendering and filtering without special-casing every notification type.

Notifications require several derived states beyond the raw list. The total unread count drives badge indicators in navigation. Notifications grouped by conversation or entity provide a collapsed view. Filtered subsets for each notification category support tabbed notification centers. Compute all these derived values from a single normalized notification store keyed by notification ID. Avoid storing derived counts separately as they go out of sync with the source data. React Query or Zustand with selectors handles this efficiently.

When a user clicks a notification to mark it as read, update the read state and decrement the unread count instantly in local state without waiting for the server confirmation. If the server call fails, roll back the state change. The vast majority of mark-as-read operations succeed, so users should never perceive latency on this interaction. Implement mark-all-as-read with the same optimistic approach, immediately setting all notifications to read locally before confirming with the server.

When a user receives fifty notifications about comments on the same post, displaying them individually overwhelms the notification center. Group notifications by a defined grouping key such as the entity being acted upon. Render the group as a single collapsed item showing the count and the most recent actors. Expand the group on click to reveal individual notifications. Send grouped notification payloads from the server for summarized push notifications showing three people and forty-seven others commented on your post.

Users must control which notifications they receive and through which channels. Build a notifications settings page where users configure preferences per notification category and per delivery channel including in-app, email, and push. Store preferences server-side scoped to the user account so they apply across all devices. The notification delivery system reads preferences before dispatching. Implement a one-click unsubscribe link in every email notification that directly updates the preference without requiring the user to navigate to settings.

When a user has the application open in multiple browser tabs, marking a notification as read in one tab must instantly reflect in all other tabs. Use the BroadcastChannel API to post notification state change messages to all tabs sharing the same origin. When a tab receives a broadcast message indicating a notification was read, update the local state immediately without a server round trip. When a new notification arrives via SSE, broadcast it to all tabs so every tab shows the notification simultaneously.

In-app notifications only reach users while they have the application open. Web Push delivers notifications to the browser even when the application is closed using the Push API and service workers. Request notification permission after a meaningful interaction, never on the first page load. Subscribe the user to your push service and store the subscription endpoint on the server. Send push messages through your push service which delivers them to the browser. The service worker receives the push event and displays the notification using the Notifications API.