Designing a Notification System

The plain-language idea

The prompt: "Design the frontend architecture for a notification system" — an in-app notification center, an unread badge count, and a way for a new notification to actually reach the client in real time. This lesson works it through end to end, applying the framework from earlier in this track rather than inventing a new one.

See it in a real thing: designing a notification system

Clarify requirements first. This is a direct application of the requirements-scoping lesson earlier in this track: is this in-app only, or does it include push notifications too? Does the unread count need to stay in sync across multiple open tabs or devices for the same user, or is per-session state acceptable? Each answer changes the design that follows — push notifications pull in a service worker and a backend push provider; in-app-only is a much smaller surface.

The real architectural pieces, assuming push is out of scope and the answer is "in-app only, but the badge should update live":

• A notification data model with explicit read/unread state per notification — something like an id, a message, a timestamp, and a boolean read flag per record, not just a flat list of strings.
• A real-time delivery mechanism for new notifications reaching the client. This is exactly the decision the previous lesson's polling/SSE/WebSocket framework exists for: notifications are server-to-client only (the client never sends a notification back over that channel) and a few seconds of latency is usually fine, so SSE — or even plain polling for a lower-urgency product — is a defensible, lighter choice than reaching for a WebSocket by default.
• A client-side store holding the notification list, with the unread count derived from it rather than tracked as a separate piece of state.

The coordination detail that trips people up: marking one notification "read" has to update two things consistently — that notification's own state, and the aggregate unread badge count. This is exactly why the earlier lesson on normalized client state matters here: if the notification list and the badge count are two independently-updated pieces of state, they will drift out of sync (a notification opens, its read flag flips, and the badge count forgets to decrement). Deriving the badge count from the notification list itself, instead of storing it separately, makes that class of bug structurally impossible rather than something to remember to handle.

What people usually miss

Watch out

• The unread badge count is a derived value, not a separate source of truth. Storing it independently from the notification list is the single most common way this feature quietly breaks — some code path updates one and forgets the other.
• "Real-time" doesn't automatically mean WebSockets here. Notifications are one-directional and usually latency-tolerant; jumping straight to a WebSocket without applying the earlier decision framework is exactly the over-engineering the previous lesson warns about.
• Cross-tab and cross-device sync are different problems being asked about in the same question. "Does the unread count sync across devices" is a real-time/server question; "does it sync across tabs in the same browser" is a separate, same-browser problem — worth naming as two different things rather than one.
• Requirements-first isn't optional flavor text for this prompt — whether push is in scope changes the entire shape of the answer, so skipping that question and guessing wastes the strongest opening move available.

Why this matters in interviews

"Design a notification system" is one of the most commonly asked frontend system design prompts precisely because it touches requirements scoping, a real-time delivery choice, and client state design all in one question — a strong answer visibly connects all three instead of treating them separately.