Designing an Enterprise-Grade Message Push Architecture: A Deep Dive

Push Capability Evolution

Stage 1 – Modular

In early internal systems with low traffic each business service built its own isolated push module (chat, SMS, email, websocket). The implementations were fragmented and quality varied across services.

Stage 2 – Framework

To eliminate duplication a unified push framework was created as a set of Spring Boot starters (chat, SMS, email, websocket) packaged inside the service‑governance framework. All microservices share the same starters and are managed uniformly.

Stage 3 – Service

When push volume grew the framework was extracted into a dedicated push service that must handle large data volumes, cross‑database queries and high concurrency, requiring substantial hardware and operational investment.

Position of the Push Service in a Business System

In a typical layered architecture the push service sits between the access layer (API gateway) and the atomic services that provide reusable capabilities such as comment, file storage, authentication, etc. For example, Bilibili extracts its comment functionality as an atomic service so that video, article and community modules can reuse it without tight coupling.

Functional Requirements

Send notifications

Prioritize notifications

Respect user preferences

Support single‑message and batch‑message delivery

Provide analysis 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 for Android, iOS and web browsers

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

Push System Design – Components

Notification client – simple and batch clients invoke the notification services via REST APIs.

Notification service – exposes REST endpoints, builds messages using the template service and validates them.

Template service – manages OTP, SMS, email and chat templates; provides UI and CRUD APIs.

Message distribution service – schedules immediate or delayed delivery with granularity from seconds to years.

Event priority queue – three topics (low, medium, high) receive messages according to business priority.

General outbound processor – polls the priority queues and dispatches messages to adapters based on priority.

Notification adapters – concrete adapters for QQ, WeChat, in‑app, email, SMS, OTP, etc.

Channel providers – external SaaS providers such as AWS SNS, MailChimp that actually deliver the messages.

User selection service – determines target users or application modules for a notification.

User profile service – stores user preferences, maps internal IDs to external channel IDs, handles unsubscribe and frequency control.

Analysis service – extracts data from Cassandra and MySQL, produces usage statistics, trends and reports.

Notification tracker – monitors the event queue and records metadata (transmission time, status, channel, type).

Notification database – MySQL cluster with a leader for writes and followers for reads, optimised for write‑heavy workloads.

High‑priority notifications are processed first; medium priority is used for transactional messages such as email; low priority handles bulk notifications outside working hours. The outbound processor routes messages to the appropriate adapters based on device type and channel.

Database Design

The notification database is a MySQL cluster where the leader handles all write operations and read replicas serve query traffic. This "write‑more, read‑less" design provides high throughput, low latency and resilience – a node failure does not lose messages because replicas keep the data synchronised.

Code example

1.
我的私密学习小圈子，从0到1手撸企业实战项目~
2.
面试官：RAG 中的混合检索是什么？为什么要用混合检索而不是纯向量检索？
3.
字节面试官：post 为什么会发送两次请求？
4.
面试官：RAG 固定大小分块有什么问题？