Backend Development 8 min read

Design and Implementation of a Notification System (Part 1) – Requirements Analysis, Data Model, and Key Process Design

This article introduces the design of a standalone notification‑system microservice, covering its functional requirements, conceptual and logical data models, and key workflow diagrams to guide implementation in Java‑based internet projects.

Java Captain
Java Captain
Java Captain
Design and Implementation of a Notification System (Part 1) – Requirements Analysis, Data Model, and Key Process Design

Message notification system (notification‑system) is a standalone microservice that fully handles all backend notification functions for the App, integrating with article, order, member, and other business systems as a low‑level common service.

Typical notification types include comment, like, favorite, order, activity, and personal‑center notifications; the system must meet high scalability, performance, availability, and data consistency requirements to improve user engagement and support core business growth.

The article is divided into two parts: the first part (this article) covers requirement analysis, data model design, and key process design; the second part will discuss technology selection, backend API design, and key logic implementation.

1. Requirement Analysis

The requirements are broken down into four sub‑requirements: sending notifications, withdrawing notifications, notification count, and notification list.

1.1 Send Notification

The operation is typically triggered by a business system, which may be the App or the admin backend.

App‑initiated notifications are usually generated by the member themselves, e.g., a reply to a comment triggers a comment‑reply notification to the original commenter.

Admin‑initiated notifications are sent by administrators from the backend, e.g., sending a prize‑winning notification for an activity.

1.2 Withdraw Notification

This optional operation is usually performed by the business system, typically via the admin backend; it is rarely done directly from the App.

The admin backend can withdraw a single or multiple sent notifications, causing the App’s notification list and unread count to update accordingly.

1.3 Notification Count

Add a notification icon in the App’s “My” module, named “Notification”.

When new notifications arrive, display the number of unread messages (red badge) representing the total unread count for the user.

Increment the count by 1 for each new unread message and decrement by 1 when a message is withdrawn.

The unread count must be consistent with the unread count shown in the notification list.

1.4 Notification List

Clicking the “Notification” icon opens the notification list, which is divided into tabs based on notification type.

The list shows all notifications received by the user, ordered by notification time descending.

New messages are marked with a red dot; after viewing, the status changes to read and the dot disappears.

Clicking a specific message may open a link, view an image‑text, or navigate to an article, depending on the content type.

2. Data Model Design

The system’s data model consists of two parts: database and cache. The conceptual model (E‑R diagram) and logical model (table design) are presented, while cache structures will be described in the implementation chapter.

2.1 Conceptual Model

The system uses three tables: notification (notification records), notification_config (notification configuration), and external_sys (external systems). The E‑R diagram shows a one‑to‑many relationship between notification and notification_config .

E‑R Diagram 1

external_sys records information about external business systems for identity verification when they call the notification system API.

E‑R Diagram 2

2.2 Logical Model

Key fields of each table are shown below.

notification table design

notification_config table design

external_sys table design

3. Key Process Design

A simplified swim‑lane diagram of the business flow is provided, followed by a sequence diagram (excluding withdrawal) to illustrate the core process.

Business Process Swim‑Lane Diagram

Business Process Sequence Diagram

Conclusion of This Part

This concludes the design and implementation of the notification system in a Java internet project (Part 1). The next part will cover technology selection, API design, and key logic implementation.

The design articles are based on extensive practice and verification; any shortcomings or errors are welcome to be pointed out, and readers are encouraged to discuss in the comments.

backendData ModelingMicroservicenotification systemprocess design
Java Captain
Written by

Java Captain

Focused on Java technologies: SSM, the Spring ecosystem, microservices, MySQL, MyCat, clustering, distributed systems, middleware, Linux, networking, multithreading; occasionally covers DevOps tools like Jenkins, Nexus, Docker, ELK; shares practical tech insights and is dedicated to full‑stack Java development.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.