Design and Implementation of a Message/Notification System

Product Analysis The article first compares how two platforms, Jiǎnshū and Zhihu, implement messaging. Both provide two main types of user‑to‑user messages (private messages) and system‑generated notifications, which are further classified into Announce, Remind, and Message.

Message Classification Announce: system‑wide broadcast. Remind: system‑generated, fixed‑format notification often containing a hyperlink. Message: user‑to‑user private message.

Reminder Language Analysis A reminder can be expressed as "someone do something in someone's something" where someone is the sender, do something is the action (comment, like, follow), something is the target object, and someone's is the target owner. Additional fields such as targetType and subscribReason may be added for extensibility.

Push vs Pull Retrieval Push (push) requires maintaining a list of followers for a specific item and sending notifications when the condition is met. Pull (pull) involves each user keeping a list of items they follow and periodically polling for new events.

Subscription Model A subscription is defined by three core attributes: target , targetType , and action . Users can also set a subscribReason that maps to a set of actions, and a SubscriptionConfig table stores per‑user preferences with a default fallback.

Core Entities (Five) 1. UserNotify – stores each user's notification queue. 2. User – user profile. 3. Subscription – records a user's subscription to a target/action. 4. SubscriptionConfig – user‑level subscription settings. 5. Notify – the notification record, with sub‑types Announce, Remind, Message.

Behavior Decomposition The system supports operations such as creating notifications, subscribing/unsubscribing, managing subscription configs, pulling notifications, retrieving a user's queue, and marking notifications as read.

Model Design Notify schema: id: {type: 'integer', primaryKey: true}, content: {type: 'text'}, type: {type: 'integer', required: true, enum: [1,2,3]}, // 1=Announce,2=Remind,3=Message target: {type: 'integer'}, targetType: {type: 'string'}, action: {type: 'string'}, sender: {type: 'integer'}, createdAt: {type: 'datetime', required: true}

UserNotify schema: id: {type: 'integer', primaryKey: true}, isRead: {type: 'boolean', required: true}, user: {type: 'integer', required: true}, notify: {type: 'integer', required: true}, createdAt: {type: 'datetime', required: true}

Subscription schema: target: {type: 'integer', required: true}, targetType: {type: 'string', required: true}, action: {type: 'string'}, user: {type: 'integer'}, createdAt: {type: 'datetime', required: true}

SubscriptionConfig schema: action: {type: 'json', required: true}, user: {type: 'integer'}

NotifyConfig (static configuration) defines allowed targetType values (PRODUCT, POST), allowed action values (COMMENT, LIKE), mapping from reason to actions, and the default subscription settings.

NotifyService API Methods include: createAnnounce(content, sender) , createRemind(target, targetType, action, sender, content) , createMessage(content, sender, receiver) , pullAnnounce(user) , pullRemind(user) , subscribe(user, target, targetType, reason) , cancelSubscription(user, target, targetType) , getSubscriptionConfig(userID) , updateSubscriptionConfig(userID) , getUserNotify(userID) , read(user, notifyIDs) . Each method’s processing logic is described in detail, covering database inserts, queries, and filtering based on subscription configs.

Sequence Diagrams The article provides visual sequence diagrams (images) illustrating the flow for reminder subscription/creation/pull and for announcement creation/pull, showing how the service methods are invoked during user actions.

Conclusion The design demonstrates a modular backend architecture for a scalable notification system, combining push and pull mechanisms, flexible subscription rules, and clear service interfaces to support announcements, reminders, and private messages.