Designing a Scalable Enterprise Unified Push Service: From Modules to Micro‑services

Architecture Goal

Provide a language‑agnostic, enterprise‑grade push platform that can deliver notifications through email, SMS, chat (WeChat/QQ), DingTalk, Enterprise WeChat, and generic web/mobile push channels via a single reusable library.

Evolution of the Push Capability

Stage 1 – Modular

Each low‑traffic system implemented its own ad‑hoc push module (chat, SMS, email, WebSocket). The approach was simple but resulted in scattered code, inconsistent quality, and duplicated effort.

Stage 2 – Framework (Spring‑Boot Starters)

A unified push framework was built as a set of Spring‑Boot starters (chat, SMS, email, WebSocket). The starters were packaged into the service‑governance layer so that every microservice could share configuration and lifecycle management, eliminating repeated design work.

Stage 3 – Dedicated Push Service

When push usage grew to high‑throughput, cross‑database query scenarios, the functionality was extracted into an independent push service. This service must handle large data volumes and high concurrency (QPS > 10 000), which justifies dedicated hardware and operational investment while allowing other services to avoid replicating the same cost.

Position in Business Architecture

The push service is an atomic service in the typical three‑layer stack:

Access Layer : API gateway that receives external requests.

Application (Aggregation) Layer : composes business‑level APIs and calls atomic services.

Atomic Services Layer : reusable technical services such as comment, file storage, authentication, and the push service.

Example: Bilibili’s comment service is an atomic service shared by video, article, and community modules; the push service is intended to be reused in the same way.

Functional Requirements

Send notifications (single and batch).

Prioritize messages (high, medium, low).

Honor user preferences (channel selection, unsubscribe, frequency limits).

Provide analytics use cases and generate reports.

Non‑Functional Requirements (NFR)

Performance : QPS > 10 000.

Availability : 99.99% uptime.

Latency : TP99 < 10 ms.

Scalability : plug‑in architecture to add adapters/providers without code changes.

Cross‑Platform : support Android, iOS, and desktop browsers.

Self‑Scaling : deployable on VMware Tanzu, AWS, GCP, or Azure.

Push System Design Architecture

The system consists of the following components, each with a clear responsibility and API contract.

1. Notification Clients

Simple Notification Client : invokes the simple notification service for one‑off messages (e.g., password reset).

Batch Notification Client : invokes the batch service for bulk campaigns (e.g., internal announcements).

2. Notification Services

Simple Notification Service : REST endpoint that builds a message, applies a template, validates payload, persists the record, and returns a send result.

Batch Notification Service : REST endpoint that accepts a list of recipients, stores each message, logs activity, and provides an API to re‑send or query historic batches.

3. Template Service

Manages OTP, SMS, email, and chat templates. Exposes CRUD REST APIs and a UI dashboard for template creation, versioning, and preview.

4. Message Dispatch Service

Offers scheduling APIs that accept a delivery time or recurrence pattern. Supported frequencies include seconds, minutes, hourly, daily, weekly, monthly, yearly, and custom cron‑like expressions.

5. Message Validation Service

Validates payloads against business rules (required fields, channel‑specific limits). Batch submissions require admin approval before they are enqueued.

6. Message Prioritization Service

Assigns a priority level (high/medium/low) based on message type, expiry, and business policy. High‑priority messages are always sent first; low‑priority messages are deferred to off‑hours.

7. Event Priority Queues

Three RocketMQ topics (high, medium, low) receive messages from the prioritization service. Consumers poll the appropriate topic according to priority.

8. Generic Outbound Processor

Continuously polls the three priority queues, transforms the internal message format, and forwards each record to the matching notification adapter.

9. Notification Adapters

QQ Adapter

WeChat Adapter

In‑app (mobile/web) Adapter

Email Adapter

SMS Adapter

OTP Adapter

Adapters encapsulate channel‑specific SDK calls, rate‑limit handling, and error‑retry policies.

10. Channel Providers

External SaaS services (e.g., AWS SNS, MailChimp, third‑party SMS gateways) that actually deliver the messages. The adapter abstracts provider differences.

11. User Selection Service

Provides APIs to resolve target users or groups based on AD/IAM, eDirectory, or custom user‑group definitions. Supports both module‑level and group‑level targeting for batch sends.

12. User Profile Service

Maintains the mapping between internal user IDs and channel‑specific identifiers (DingTalk ID, Enterprise WeChat ID, email address). Exposes preference APIs for unsubscribe, channel opt‑in/out, and frequency limits.

13. Analytics Service

Extracts notification records from Cassandra (event store) and MySQL (transactional store) to produce reports such as:

Total notifications per second/day.

Most frequently used channel.

Average message size and send frequency.

Priority‑filtered usage patterns.

14. Notification Tracker

Monitors the event‑center queues, captures metadata (timestamp, status, channel, type) for each notification, and writes it to the tracking store for audit and debugging.

15. Notification Database (MySQL Cluster)

Leader‑follower cluster optimized for write‑heavy workloads. Writes go to the leader; reads are served by followers. The schema stores message ID, user ID, channel, priority, status, timestamps, and retry count. The design follows a "write‑more, read‑less" pattern to meet the high QPS and low‑latency goals.

End‑to‑End Flow

Client (simple or batch) calls the appropriate Notification Service.

Service retrieves a template from the Template Service.

Message payload is validated by the Validation Service.

Prioritization Service assigns a priority and publishes the message to the matching RocketMQ topic.

Generic Outbound Processor consumes the message, looks up target users via User Selection Service and channel IDs via User Profile Service.

Processor routes the enriched message to the correct Adapter.

Adapter invokes the external Channel Provider (e.g., AWS SNS) and reports success/failure back to the Tracker.

Analytics Service periodically aggregates data for dashboards and reports.

The diagram below visualizes the component interactions:

Trade‑offs and Rationale

Extracting push logic into a dedicated service incurs additional infrastructure cost but centralizes high‑throughput handling, reduces duplicated hardware across microservices, and enables focused performance tuning.

Plug‑in adapter design avoids recompiling the core service when adding a new channel, at the expense of maintaining a stable adapter contract.

Using RocketMQ for priority queues provides reliable ordering and horizontal scaling, but requires operational expertise for cluster management.

MySQL leader‑follower architecture satisfies low‑latency writes but introduces eventual consistency for read‑only analytics, which is mitigated by the separate Cassandra store for real‑time event queries.

Code example

相关阅读：