Katkat

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

RobloxSoftware Engineer · Onsite

Last updated

A system design question about an in-app notification center that turns product events into per-user notifications, shows an unread badge and a recent list, and pushes new items to online users. It tests fan-out strategy, inbox data modeling, unread counts, real-time delivery, reliability, and client design.

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.

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?

Hints

Hint 1

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 2

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 3

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.

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?