Designing an Enterprise‑Level Unified Notification Service Architecture

The article begins by presenting common interview questions about enterprise‑level notification systems and then proposes a comprehensive architecture that showcases strong technical capabilities.

Architecture Goals : Build a unified push service that can deliver notifications via multiple channels such as email, SMS, chat apps (WeChat, QQ), DingTalk, and enterprise WeChat, supporting both on‑device and off‑device scenarios.

Evolution of Push Capability :

Stage 1 (Modular): Each business system implements its own isolated push module (chat, SMS, email, WebSocket), leading to fragmented implementations.

Stage 2 (Framework): Introduce a common push framework with Spring‑Boot starters for chat, SMS, email, and WebSocket, enabling unified configuration and management.

Stage 3 (Service‑Oriented): Consolidate the framework into a dedicated push service that addresses high data volume and high concurrency, reducing hardware and operational costs.

Position in Business Systems : The push service sits between the API gateway (access layer) and the business logic (application layer), providing reusable atomic services such as comment, file storage, and authentication.

Functional Requirements : Send notifications, prioritize them, respect user preferences, support single and batch messages, provide analytics and reporting.

Non‑Functional Requirements (NFR) : High performance (QPS > 10,000), 99.99% availability, latency <10 ms (TP99), extensibility for new adapters, cross‑platform support (Android, iOS, web), and auto‑scaling on private or public clouds.

System Design Components :

Notification Clients (simple and batch) that invoke APIs.

Notification Services (simple and batch) that construct messages, invoke template and validation services, persist messages, and expose management APIs.

Template Service for managing OTP, SMS, email, and chat templates.

Message Dispatch Service with scheduling capabilities (seconds to years).

Message Validation Service for business rule enforcement.

Priority Service that classifies messages into high, medium, and low queues.

Event Priority Queues (e.g., RocketMQ) handling three priority topics.

Generic Outbound Processor that routes messages to appropriate adapters based on priority and channel.

Notification Adapters for QQ, WeChat, in‑app, email, SMS, OTP, etc.

Channel Providers (e.g., AWS SNS, MailChimp) that perform actual delivery.

User Selection Service for targeting users or groups, integrating with AD/IAM directories.

User Profile Service managing user preferences and identifiers across channels.

Analytics Service extracting data from Cassandra and MySQL for reporting usage trends.

Notification Tracker monitoring delivery metadata.

Notification Database (MySQL cluster) storing all notification records with leader‑follower replication for high availability.

The design emphasizes modularity, scalability, high availability, and low latency, enabling enterprises to deliver reliable, multi‑channel notifications while minimizing duplicated effort and operational costs.