Design an In-App Notification Center with Real-Time Updates and Unread Counts

Design a notification center for a large consumer platform. Other parts of the product generate events that a user should hear about, for example a friend request, a reply to their post, or a platform announcement. The notification center shows each user a bell icon with a count of unread notifications and, when opened, a list of their recent notifications, newest first. Users can open a notification, mark one or all of them as read, and see new notifications appear while they are online, without refreshing the page. A user who was offline sees everything they missed when they come back. ```hint Write path versus read path Separate what happens when an event produces a notification from what happens when a user opens the bell. The two have very different volumes and latency needs. ``` ```hint The badge is its own problem The unread count is read on almost every page view. Consider whether computing it from the notification list each time is affordable. ``` ```hint Online and offline Decide how a notification reaches a user whose browser is open right now, and what a user who was offline, or whose connection dropped, sees when they return. ``` ### Constraints and Clarifications - Treat the in-app notification center (the bell, its badge and the list) as the core scope. Mobile push and email are optional channels to confirm. ### Clarifying Questions - Should the design cover the client, the backend, or both end to end? - Which channels are in scope: only in-app, or also mobile push and email? - How many users and notifications per day are expected, and how long are notifications kept? - Do some events go to very many users at once, such as an announcement to everyone or an update to all followers of a popular account? - Should similar notifications be grouped (for example, "Sam and 9 others replied"), and is ordering strictly by time? - Can users mute notification types or choose channels per type? ### What a Strong Answer Covers - Requirements and scope, including multiple devices and the online, offline and reconnecting cases - A data model and storage choice for per-user notification lists and read state, and how they are partitioned - A generation and fan-out pipeline, including very large audiences, preference filtering and rate limiting - Real-time delivery to connected clients, plus catch-up for clients that reconnect - An unread count that is cheap to read and stays consistent with mark-as-read actions - Client architecture (badge, paginated list, optimistic updates, deduplication across tabs), reliability and observability ### Follow-up Questions - A platform-wide announcement must reach every user. How does your fan-out handle it without delaying normal notifications? - A user has the site open in three tabs and on a phone. How do read state and the badge stay in sync? - How would you group repeated notifications, such as many replies to the same post? - A node of the real-time connection service fails. What does the user see, and how do clients recover?