Design and Implementation of an Integrated Push Notification Platform

1 Background

Zhuanzhuan’s various businesses frequently need to push different messages to different user groups, such as daily red‑packet coupons for new book users, weekly reminders for luxury‑goods users, event‑driven announcements, and push‑plus‑SMS alerts for game merchants.

These requirements share common characteristics: diverse push subjects, varying target audiences, multiple data sources (HiveSQL, user‑profile platform, manual Excel), numerous channels (red‑packet, push/IM, SMS, WeChat), customizable content with placeholders, different frequencies, and distinct business goals (acquisition, re‑engagement, reminders).

Each new push currently requires repetitive coding to handle configuration, deduplication, asynchronous execution, speed control, and metric collection, leading to redundant code and high maintenance cost.

Therefore a generic push platform is needed to unify and manage these demands.

2 Design Idea

The overall design follows the principle of “configuring the variable parts and systematizing the invariant parts.”

2.1 Configuring the Variable Parts

A push‑configuration table stores one record per push request, abstracting mutable attributes such as business side (enum), push type (multi‑channel list), content fields (title, copy, landing page, image, red‑packet plan ID) with placeholders (e.g., ${orderId}), and user‑source details (HiveSQL file ID/API key, audience ID, or uploaded Excel).

2.2 Systematizing the Invariant Parts

Common logic is extracted into a reusable subsystem, including a user table (userId, configId, result, failure reason), mapping configuration and user data into a push context, pre‑push deduplication and rate‑limit checks, asynchronous execution with thread‑pool and QPS throttling, and post‑push result persistence.

3 Implementation Details

3.1 Speed Control

Asynchrony : Main thread reads data and submits tasks to a thread‑pool, allowing concurrent pushes.

Additional techniques:

Sharding : Distribute tasks across a cluster using id % machineCount to balance load.

Checkpoint Retry : Store last processed ID in Redis for each machine to resume after failures.

Interface Rate Limiting : Apply global QPS limits on RPC calls.

3.2 Resource Allocation Strategy

Four strategies were evaluated; the final choice is “uniform distribution” because it guarantees fairness without extra table scans.

Priority‑based ordering (simple but can starve low‑priority configs).

Data‑size based allocation (fair but requires pre‑scan).

Uniform distribution (equal share per config, simpler and efficient).

3.3 Problem Solving

Full GC occurred under ten‑million‑scale pushes due to the main thread outpacing the thread‑pool, causing queue buildup.

Solution: switch to a producer‑consumer model with a bounded blocking queue, letting the producer block when the queue is full and the consumer pull tasks, eliminating memory pressure.

Result: Full GC disappeared and old‑generation usage dropped significantly.

4 Online Effects

The platform is now visualized in the business backend and open to multiple teams. Creating a new push only requires adding a configuration record; the system handles user sourcing, execution, and result reporting.

Since launch, daily push volume reaches millions, with peaks up to 20 million pushes.

5 Summary

The integrated push platform has become a common tool for Zhuanzhuan’s daily and campaign messaging, and future work will focus on conversion‑rate optimization and targeted result notifications.