30% offEnding soon
FSD-008Frontend system design Premium

Design a Toast and Notification-Center System

Design durable notification records, bounded toast queues, an in-product center, deduplication, accessible urgency, and hidden-tab behavior.

Intermediate 43 min read

Store notification records once, then let independent delivery policies decide whether an event belongs in durable history, a transient toast, an unread badge, or an operating-system notification. Bound interruptions, deduplicate repeated events, and keep accessibility urgency separate from business priority.

A save confirmation, a failed payment, and a new team invitation are all called notifications. They should not behave the same way. The design becomes manageable once the durable fact is separated from the way that fact reaches a person.

Start with records and delivery channels

The source of truth is a notification record with an event identity, recipient scope, timestamps, read state, destination, and safe display data. A delivery policy may project that record into one or more channels:

  • toast for timely feedback in the current viewport;
  • notification center for durable history;
  • badge for a compact unread signal;
  • browser or operating-system notification for an allowed return path;
  • email or another external channel when product policy requires it.

The channels share the event, not their interruption rules. Closing a toast must not delete the history record. Reading the history record may clear a badge without recalling an operating-system notification that was already delivered.

The public interview prompt

Design a reusable toast and notification-center system. Explain:

  • event normalization, recipient scope, durable records, read state, and preferences;
  • toast eligibility, priority, bounded queues, deduplication, timers, and dismissal;
  • in-app history, pagination, optimistic updates, cross-tab and cross-device synchronization;
  • polite status messages, urgent alerts, keyboard access, reduced motion, and zoom;
  • hidden documents, offline use, reconnects, retries, ordering, and idempotency;
  • browser push permission, service workers, deep links, privacy, and retention;
  • performance, observability, testing, rollout, and evolution.

Assume a signed-in web application. Version one supports in-product toasts, a durable notification center, unread badges, and optional browser notifications. Email campaigns, mobile-native push infrastructure, and marketing automation are outside the first release.

What the premium solution covers

The complete solution defines the notification record, ingestion and delivery boundaries, toast scheduler, priority and preemption policy, deduplication keys, hidden-tab behavior, live-region lanes, notification-center pagination, optimistic read state, cross-tab coordination, offline reconciliation, browser push consent, privacy, observability, deterministic tests, rollout, and an interview scoring rubric.

Original media follows repeated and urgent events through a bounded toast queue. A separate visual compares toast, durable center, and operating-system delivery. A deterministic lab lets you enqueue repeats, promote an urgent alert, hide the document, and inspect the resulting queue and announcement lane.

Premium solution

Continue with the complete system design

Unlock the architecture, state machine, API contracts, original diagrams, positioning model, accessibility decisions, performance budgets, testing plan, rollout strategy, scoring rubric, and interview walkthrough.

  • Detailed, beginner-friendly explanation
  • Production failure modes and trade-offs
  • Mobile-friendly architecture diagrams
  • Senior and staff-level interview signals
Unlock Premium

Frequently asked questions

What is the difference between a toast and a notification center?
A toast is a short-lived presentation for timely feedback in the current viewport. A notification center is durable product history with read state, pagination, and cross-device synchronization. The same event may create both, but they have different lifetimes and interaction contracts.
Should every notification appear as a toast?
No. Frequent, low-value, stale, or background events should usually enter durable history without interrupting the current task. Toast eligibility is a delivery policy based on urgency, visibility, user preference, and deduplication.
How should duplicate notifications be handled?
Give related events a stable deduplication key and a time window. Update a count or summary on the existing record instead of producing repeated interruptions. Keep idempotency at ingestion separate from presentation grouping.
When should a toast use an assertive live region?
Reserve assertive announcements for genuinely urgent conditions that require immediate attention. Ordinary confirmations and progress updates should use a polite status region so they do not interrupt the screen reader's current speech.
What happens to toast timers when the browser tab is hidden?
Pause or suppress transient presentation while the document is hidden. Preserve the durable record, then decide on return whether the information is still timely enough for a toast. Do not let a hidden timer consume the message before the user can perceive it.
How do browser push notifications fit the design?
Browser push is an optional return channel with separate user permission, privacy, routing, and service-worker requirements. It should consume the same normalized records and preferences without becoming the source of truth for in-product history.