Design Notification System

1. What does a notification system do?

A notification system alerts users when an event elsewhere in the product may deserve their attention. For example, a social application might notify a user that "someone you follow published a new post." Although the user sees only a compact push banner, the underlying system must handle fanout, manage traffic bursts, and recognize that asynchronous push providers are external side effects rather than the authoritative record.

<img src="https://cgppcnnkwbfiieexbrea.supabase.co/storage/v1/object/public/question-images/sources/5d7ea23430384348adc0.png" alt="" width="450" preview/>

2. Requirements

High-level architecture and data flow of the notification system

Publishing a post should remain inexpensive, while the notification system asynchronously converts that action into large-scale, attention-conscious push delivery without overwhelming recipients or relying on providers as the system of record.

Functional requirements

• After an author creates a post, durable work for follower notifications must be recorded without performing complete fanout or contacting providers within the publishing request.
• Pushes must be sent to followers' devices through third-party services such as APNS, FCM, or Web Push.
• Before delivery is attempted, the system must honor notification settings and relationship mutes, and it must use only valid device tokens.
• Provider failures must follow a bounded retry policy; attempts that fail permanently must be routed to cleanup or dead-letter handling rather than retried forever.
• If a recipient accumulates many reminders over a brief interval, the system must combine them into fewer pushes while retaining a canonical way to recover unread items.

Non-functional requirements

• Aim for 99.99% durability when creating notification intent and 99.9% successful handoff to providers inside a healthy region.
• Keep the synchronous enqueue operation on the publishing path near p95 < 100 ms, with ordinary pushes arriving within several seconds outside burst conditions.
• Support approximately 10M post events each day, 100B+ follow relationships, peak publishing volume of roughly 5k/s, and celebrity accounts with 50M+ followers.
• Notification intents, aggregation data, retry timing, and provider-attempt outcomes must survive worker and node failures.
• Delivery semantics should be at-least-once, with best-effort deduplication for end users; provider acceptance means the handoff succeeded, not that a person viewed the push.
• Failures must be isolated so that a hot author, a noisy tenant, or a malfunctioning provider route does not deprive unrelated recipients of service.
• Producers must be authorized, device tokens must remain scoped to users, and the design must resist replay, duplicate fanout, and retry storms.
• Brief aggregation windows should reduce provider traffic and prevent the same user from receiving floods of low-value pushes.

Back-of-the-envelope estimation

At these scales, the architecture should acknowledge publishing quickly, perform fanout asynchronously, aggregate by recipient, and allow provider-facing workers to scale separately.

A practical interview target is a straightforward user-visible limit: during bursts, keep this event category to about 1-2 pushes per recipient per minute, even when the underlying unread count grows more quickly.

[!NOTE] Use these estimates to establish orders of magnitude during the interview; they are not a final capacity-planning approval.

Out of scope (below the line)

• Implementing the follow graph, post persistence, or home-feed ranking
• Supporting email, SMS, or marketing-campaign delivery
• Designing sophisticated in-app inbox ranking, notification-grouping interfaces, or recommendation behavior
• Guaranteeing open or view measurement beyond provider acceptance and delivery signals reported by the application
• Coordinating every type of notification across all company products