Design and Evolution of an Enterprise Unified Push Service

The article presents a design for an enterprise‑level unified push service that integrates multiple notification channels—including chat (WeChat/QQ), in‑app and web push, SMS, email, DingTalk, and Enterprise WeChat—into a single, reusable framework suitable for modern distributed applications.

Evolution of Push Capability

Stage 1 (Modular): Independent and Self‑contained

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

Stage 2 (Framework): Integrated Framework

A unified push framework was introduced as a set of Spring Boot starters (chat, SMS, email, WebSocket) managed by a service‑governance platform, enabling centralized configuration and operation.

Stage 3 (Service‑oriented): Push Service

The framework evolved into a dedicated push service to handle large data volumes and high concurrency, reducing hardware costs and operational overhead.

Position of the Push Service in Business Systems

In a typical application architecture, the push service resides between the access layer (API gateway), the application/aggregation layer, and the atomic services that provide reusable business capabilities.

Functional Requirements of the Push Service

Send notifications

Prioritize notifications

Respect user preferences

Support single and batch messages

Provide analytics use cases

Generate notification reports

Non‑Functional Requirements (NFR)

High performance (QPS > 10,000)

High availability (99.99%)

Low latency (TP99 < 10 ms)

Scalable and pluggable design for new adapters and providers

Cross‑platform support (Android/iOS, web browsers)

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

Push System Design Architecture

The architecture consists of the following components:

1. Notification Clients

Simple notification client for single messages

Batch notification client for mass messaging

2. Notification Services

Expose REST APIs, build messages using the template service, validate them via the verification service, persist messages, and provide APIs for resend, CRUD, and dashboard filtering.

3. Template Service

Manages templates for OTP, SMS, email, chat, etc., and offers a UI for template administration.

4. Message Dispatch Service

Schedules immediate or timed notifications (seconds to years) and triggers automatic dispatches.

5. Message Priority Service

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

6. Event Priority Queues

Three queues (high, medium, low) receive prioritized events from the notification service.

7. Generic Outbound Processor

Consumes events from the priority queues and forwards them to appropriate adapters based on channel type.

8. Notification Adapters

QQ adapter

WeChat adapter

In‑app adapter

Email adapter

SMS adapter

OTP adapter

9. Channel Providers

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

10. User Selection Service

Determines target users or application modules, possibly integrating with AD/IAM directories.

11. User Profile Service

Manages user profiles, preferences, and mappings between internal and external identifiers, supporting unsubscribe and frequency controls.

12. Analytics Service

Analyzes notification usage, trends, and generates reports (total notifications, most used channels, average size, etc.).

13. Notification Tracker

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

14. Notification Database (MySQL Cluster)

Stores all notification records with a leader‑follower architecture optimized for high write throughput and low latency.

Finally, the article notes that knowledge of such push service architectures is a common interview topic and encourages readers to discuss and explore further.