Backend Development 16 min read

Design and Implementation of an Enterprise Unified Push Notification Service

The article outlines the design and evolution of an enterprise‑level unified push notification service, detailing its modular to service‑oriented architecture, multi‑channel support, high‑performance non‑functional requirements, and the comprehensive components such as clients, notification, template, distribution, priority queues, adapters, analytics, and database layers.

Top Architect
Top Architect
Top Architect
Design and Implementation of an Enterprise Unified Push Notification Service

Overview

The article presents a unified push notification service for enterprise applications, capable of delivering messages through multiple channels such as WeChat, QQ, SMS, email, DingTalk, and web browsers. It emphasizes the need for a common foundation that works across different programming languages and distributed systems.

Evolution of Push Capability

Stage 1 – Modular

Initially, each business system built its own isolated push modules (chat, SMS, email, websocket), leading to fragmented implementations and inconsistent quality.

Stage 2 – Framework

To reduce duplication, a unified push framework was introduced, encapsulating channel‑specific starters (chat, SMS, email, websocket) within a service‑governance framework, enabling unified configuration and operation.

Stage 3 – Service

The framework matured into a full‑featured push service that addresses high data volume, cross‑database queries, and high concurrency, requiring significant hardware and operational investment. Centralizing this functionality reduces repeated development and operational costs.

Position of the Push Service in Business Architecture

The service sits between the access layer (API gateway), the application layer (aggregation), and atomic services, providing reusable notification capabilities for various business modules.

Functional Requirements

Send notifications

Prioritize messages

Respect user preferences

Support single and batch messages

Provide analytics and reporting

Non‑Functional Requirements (NFR)

High performance: QPS > 10,000

High availability: 99.99%

Low latency: TP99 < 10 ms

Scalable, plug‑in design for new adapters and providers

Cross‑platform support for Android, iOS, and web browsers

Auto‑scaling on private and public clouds (VMware Tanzu, AWS, GCP, Azure)

System Design Architecture

1. Notification Clients

Simple client for single messages and batch client for bulk notifications, both invoking the notification services via REST APIs.

2. Notification Services

Expose APIs for simple and batch notifications, handle message construction, template rendering, validation, persistence, and activity logging. Provide CRUD operations and a web dashboard for filtering messages.

3. Template Service

Manages templates for OTP, SMS, email, chat, and other channels, offering REST APIs for creation, update, deletion, and a UI for administrators.

4. Message Distribution Service

Schedules immediate or delayed notifications (seconds to years) and triggers automatic dispatch based on configured schedules.

5. Message Validation Service

Validates message formats and business rules; batch notifications require administrator approval.

6. Priority Service

Assigns high, medium, or low priority to messages, influencing processing order.

7. Event Priority Queues

Three queues (high, medium, low) receive messages from the notification service and feed the outbound processor.

8. Generic Outbound Processor

Polls the priority queues, processes messages according to priority, and forwards them to appropriate channel adapters.

9. Channel Adapters

QQ Adapter

WeChat Adapter

In‑app Notification Adapter

Email Adapter

SMS Adapter

OTP Adapter

10. Channel Vendors

Integrates with external SaaS providers such as AWS SNS, MailChimp, and other commercial push services.

11. User Preference Service

Manages user profiles, linking internal identifiers with external channel IDs (e.g., DingTalk, WeChat) and stores notification preferences, subscription status, and frequency settings.

12. Analytics Service

Aggregates data from Cassandra and the notification database to produce metrics like total notifications per second, most used channels, message size, and priority‑based filters.

13. Notification Tracker

Monitors the event queue, tracking delivery metadata such as transmission time, status, channel, and message type.

14. Notification Database

Uses a MySQL cluster with a leader for writes and read replicas for queries, ensuring high write throughput, low latency, and strong consistency for persisted notifications.

Additional Content

The article also contains promotional material for a knowledge‑sharing community, offers free ChatGPT accounts, and lists various related resources and links.

backend architecturePush NotificationMicroservicesscalabilityHigh Availabilitynotification service
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

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.