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.
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.
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.