Backend Development 11 min read

Design and Implementation of a Unified Push Notification Platform

The article presents a comprehensive design and implementation of a unified push notification platform that abstracts variable configurations, systematizes immutable logic, and employs asynchronous processing, sharding, rate limiting, and resource allocation strategies to achieve scalable, reliable, and maintainable multi‑business push services.

Architect
Architect
Architect
Design and Implementation of a Unified Push Notification Platform

Background: Various business lines at ZhaiZhai frequently push different types of messages (red packets, in‑app cards, SMS, etc.) to distinct user groups, leading to repetitive development of push tasks and high maintenance costs.

Design Idea: Separate the "variable" aspects into configurable data and the "invariant" logic into a reusable system, enabling a single platform to handle diverse push requirements.

Configuration: Create a push configuration table where each record captures mutable fields such as business source, push type (channel list), content details (title, copy, landing page, image, red‑packet ID), and user source information (HiveSQL file ID, API key, crowd ID, or uploaded Excel).

Systemization: Build a generic backend that maintains a user‑push mapping table, transforms configuration and user data into push context entities, performs deduplication and frequency checks, executes pushes asynchronously via a thread pool, applies QPS limits, and records results back to the user table.

Implementation Details – Speed Control: Use asynchronous thread pools, shard tasks across machines based on primary‑key modulo, employ checkpoint IDs stored in Redis for resumable processing, and enforce global RPC QPS limits.

Implementation Details – Resource Allocation: Evaluate three strategies—priority‑based, data‑size‑based, and uniform distribution—and ultimately adopt uniform distribution to ensure fairness and simplicity without extra data‑size calculations.

Problem Solving: Address Full GC caused by task‑queue buildup by switching to a producer‑consumer model with a bounded blocking queue, which eliminates memory pressure and reduces old‑generation usage.

Results: After deployment, the platform supports daily push volumes of up to millions, peaks of tens of millions, and serves multiple business lines through a single visualized backend, dramatically reducing development effort and improving maintainability.

Conclusion: The unified push platform has become a common tool for ZhaiZhai’s various services, with future enhancements planned for conversion rate tracking and targeted notifications.

backend architecturepush notificationsscalabilitysystem designasynchronous processingresource allocation
Architect
Written by

Architect

Professional architect sharing high‑quality architecture insights. Topics include high‑availability, high‑performance, high‑stability architectures, big data, machine learning, Java, system and distributed architecture, AI, and practical large‑scale architecture case studies. Open to ideas‑driven architects who enjoy sharing and learning.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.