Designing an Enterprise‑Level Unified Push Service: Architecture, Channels, and Scalability

Build an enterprise‑level unified basic push service that supports multiple channels—email, SMS, chat (WeChat/QQ), DingTalk, WeCom and other public social apps—through a single integration point.

Chat – WeChat/QQ

In‑app push notifications (mobile devices and web browsers)

Out‑of‑app push notifications (when the app is not running)

SMS (e.g., login passwords, marketing campaigns)

Email

DingTalk

WeCom

The unified basic push service is a generic feature applicable to all modern distributed applications, regardless of programming language or technology stack.

Evolution of Push Capability

Stage 1 (Modular): Independent, self‑contained modules

In the early stage, each system had its own push module with varied types:

Chat module

SMS module

Email module

WebSocket module

These modules were simple but fragmented, making quality assurance difficult.

Stage 2 (Framework): Integrated framework

To reduce duplication and development cost, a unified push framework was designed.

The same micro‑service framework shares a single push framework.

To solve the scattered implementation problem, the enterprise built a comprehensive push library that business teams can call uniformly.

Chat basic starter

SMS basic starter

Email basic starter

WebSocket basic starter

The logic of spring‑boot‑starter was packaged into the service‑governance framework, so each microservice manages its starters during startup.

Stage 3 (Service‑oriented): Push Service

Integrated into the framework, each service must repeatedly solve three high‑level problems:

Push service handles large data volumes and cross‑database queries.

Push service requires high performance to meet high concurrency.

Large data and high concurrency imply heavy hardware investment and high O&M cost.

Therefore, the push framework evolved into a dedicated push service that is centrally maintained, iterated and operated by a specialized team, reducing duplicate effort and achieving cost efficiency.

Thus, pushFramework evolved into pushService.

Position of Push Service in Business Systems

A business application is composed of many atomic services orchestrated together.

Access layer : the gateway through which external requests enter the internal system.

Application layer (also called aggregation layer): provides aggregated interfaces for related business and calls middle‑platform services.

Atomic services : reusable technical or business services that expose APIs for various scenarios.

For example, a comment service on a video platform can be an independent atomic service used by videos, articles and community features.

Similarly, file storage, data storage, push service, authentication service, etc., are all distilled into atomic services that developers compose to build applications quickly.

Push Service Functional Requirements

Send notifications

Prioritize notifications

Send notifications according to user preferences

Support single/simple and batch notifications

Provide analysis use cases for various notifications

Generate notification reports

Push Non‑Functional Requirements (NFR)

High performance: QPS > 10,000

High availability (HA): 99.99%

Low latency: TP99 < 10 ms

High scalability: pluggable design to add more adapters and providers

Cross‑platform: support Android/iOS devices and desktop/web browsers

Auto‑scaling: scale on‑premises (VMware Tanzu) and public clouds such as AWS, GCP or Azure

Push System Design Architecture

The solution consists of the following components:

1. Notification Clients

Clients call APIs to request single or batch messages and send them to simple or batch notification services.

Simple notification client : sends a single notification (e.g., password reset, account alert).

Batch notification client : sends notifications to many users (e.g., internal announcements, marketing campaigns).

2. Notification Services

These services expose REST APIs to interact with clients, build notification messages via the template service, and validate them via the verification service.

Simple notification service : provides an API for low‑volume, single‑user notifications.

Batch notification service : provides an API for high‑volume, bulk notifications.

They persist messages to a database, maintain activity logs, support CRUD operations on messages, and offer a web dashboard with filtering capabilities.

3. Template Service

Manages templates for OTP, SMS, email, chat and other push messages, offering REST APIs for create, update, delete and management, as well as a UI dashboard.

4. Message Dispatch Service

Provides scheduling APIs for immediate or timed delivery (seconds, minutes, hourly, daily, weekly, monthly, yearly, or custom frequencies).

5. Message Verification Service

Validates notification content according to business rules; bulk notifications require admin approval.

6. Message Priority Service

Ranks notifications into high, medium and low priority levels; high‑priority messages are always sent first.

7. Event Priority Queues (Message Queues)

Three queues (low, medium, high) receive notifications based on priority and forward them to the outbound processor.

8. Generic Outbound Processor

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

9. Notification Adapters

Convert messages from the internal queue to external partner formats. Examples include:

QQ notification adapter

WeChat notification adapter

In‑app notification adapter

Email adapter

SMS adapter

OTP adapter

10. Channel Providers

External SaaS providers (e.g., AWS SNS, MailChimp) that actually deliver the notifications.

11. User Selection Service

Chooses target users or application modules, possibly using AD/IAM directories or custom user groups.

12. User Profile Service

Manages user profiles and preferences, maps internal user IDs to external channel IDs (e.g., DingTalk, WeCom, email), and supports unsubscribe and frequency settings.

13. Analytics Service

Analyzes notification usage, trends and generates reports (e.g., total notifications per day/second, most used channel, average message size, priority‑based filtering).

14. Notification Tracker

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

15. Notification Database (MySQL Cluster)

Stores all notification records with a leader‑follower architecture optimized for write‑heavy workloads, ensuring high availability and low latency.