Designing a Scalable Notification System: Concepts, Classification, and Implementation Strategies

Product Analysis

We first examine how two popular platforms implement messaging.

Jianshu

Jianshu separates messages into two types:

Jianxin (private messages)

Reminders (system‑generated notifications with fixed templates)

Jianxin functions like a direct message between users.

Reminders are system‑sent messages with fixed wording and often contain hyperlinks.

Zhihu

Zhihu also distinguishes two categories:

Private messages

Notifications

Private messages are similar to Jianshu’s direct messages and can be sent by users or administrators.

Zhihu’s notifications aggregate similar messages to reduce reading load.

Three Message Categories

Based on the analysis, messages can be classified into:

Announce (system‑wide announcements)

Remind (system‑generated alerts)

Message (user‑to‑user private messages)

Language Analysis of Reminders

Sample reminder texts from Jianshu reveal a common structure: " who performed action on target owned by targetOwner ." This leads to the following entity definitions:

sender : the user who triggers the reminder

action : the operation (like, follow, comment)

target : the object of the action (article, etc.)

targetOwner : owner of the target

If the target can be of different types, an additional targetType field is needed.

Message Retrieval Methods

Push: maintain a list of subscribers for a specific item and push notifications when conditions are met.

Pull: each user keeps a list of items they follow; the system polls for new events and the user pulls them.

We apply different retrieval strategies based on message type: announcements and reminders use pull, while direct messages use push.

Subscription

Pull‑based reminders require a subscription list, defined by three core attributes:

target

targetType

action

Users can also configure subscription preferences, e.g., receiving only comment notifications for a liked article.

These preferences are stored in a SubscriptionConfig table, with a fallback defaultSubscriptionConfig when no custom settings exist.

Aggregation

When multiple similar events occur (e.g., many comments on an article), the system can aggregate them into a single notification to avoid spamming the user.

Five Core Entities

UserNotify (user’s notification queue)

User

Subscription

SubscriptionConfig

Notify

Behavior Decomposition

System/Admin creates a notification: createNotify (make announce | remind | message)

User subscribes or cancels subscription: subscribe, cancelSubscription User manages subscription settings: getSubscriptionConfig, updateSubscriptionConfig User pulls notifications: pullNotify (pull announce | remind | message | all)

User queries notification queue: getUserNotify (get announce | remind | message | all)

User reads a notification: read In the next part of this series we will discuss data modeling, database schema, code structure, and sequence diagrams.