Design and Evolution of an Enterprise Unified Push Service

Push Capability Evolution

The enterprise unified push service started as isolated modules for chat, SMS, email, and WebSocket, then progressed to a shared framework (starters) integrated into a service‑governance layer, and finally matured into a dedicated push service addressing large data volumes and high concurrency.

Stage 1 – Modular

Early on, each business system built its own push module (chat, SMS, email, WebSocket), resulting in fragmented implementations and inconsistent quality.

Stage 2 – Framework‑Based

A unified push framework was created as a set of Spring Boot starters (chat, SMS, email, WebSocket) packaged within the service‑governance framework, allowing microservices to manage and configure these starters centrally.

Stage 3 – Service‑Based

The push framework evolved into a standalone push service to handle massive data and high QPS, requiring significant hardware and operational investment, but enabling cost reduction through shared maintenance.

Position of the Push Service in the Business System

The architecture consists of an access layer (API gateway), an application/aggregation layer, and atomic services such as the push service, which can be reused across multiple business scenarios.

Push Service Functional Requirements

Send notifications

Prioritize notifications

Respect user preferences

Support single and batch messages

Provide analytics use cases

Generate notification reports

Push Service 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 for Android/iOS and web browsers

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

Push System Design Architecture

The design includes the following components:

1. Notification Clients

Simple notification client – sends individual messages

Batch notification client – sends bulk messages

2. Notification Services

Expose REST APIs, build messages via the template service, validate them, persist them, and provide CRUD and replay capabilities. A web dashboard offers filtering by date, priority, user group, etc.

3. Template Service

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

4. Message Dispatch Service

Schedules immediate or timed notifications (seconds, minutes, hourly, daily, weekly, monthly, yearly, custom frequencies).

5. Message Validation Service

Validates notification payloads according to business rules; batch notifications require admin approval.

6. Message Priority Service

Assigns high, medium, or low priority to notifications; high‑priority messages are always sent first.

7. Event Priority Queues (Message Queues)

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

8. Generic Outbound Processor

Consumes events from the priority queues, routes them to appropriate adapters based on channel type and device, and ensures high‑priority handling.

9. Notification Adapters

QQ adapter

WeChat adapter

In‑app adapter

Email adapter

SMS adapter

OTP adapter

10. Channel Providers

External SaaS providers such as AWS SNS, MailChimp, etc., that actually deliver the messages.

11. User Selection Service

Selects target users or application modules, possibly integrating with AD/IAM, directories, or user groups, and respects user preferences via the profile service.

12. User Profile Service

Manages user profiles, maps external identifiers (DingTalk, WeChat, email) to internal IDs, supports unsubscribe and frequency settings, and feeds preference data to the notification service.

13. Analytics Service

Extracts data from Cassandra and MySQL to produce reports on total notifications, channel usage, message size, frequency, and priority‑based filters.

14. Notification Tracker

Monitors the event queue, captures metadata (transmission time, status, channel, type) for each notification.

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.

Conclusion

Understanding the design, evolution, and operational aspects of a unified push service equips candidates with solid answers for common interview questions and demonstrates deep expertise in building scalable backend notification systems.