High-Concurrency Mobile Push Notification Architecture: Reliable Delivery with FCM & APNs
Delivering time-sensitive alerts to millions of mobile users: handling token invalidation, exponential backoff, rate limits, and priority channel routing.
Sending critical push notifications to millions of mobile users during flash sales, breaking alerts, or rideshare updates requires serious systems engineering. Naive synchronous delivery loops choke under connection limits, hit third-party provider throttling, and deliver stale notifications hours late.
At WorkSaar, we architect high-throughput mobile notification pipelines capable of dispatching 100,000+ messages per second. We combine Redis token caches, BullMQ worker pools, and persistent HTTP/2 multiplexing directly to Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM).
"In on-demand ride hailing and flash commerce, a notification delayed by three seconds is functionally equivalent to an order lost."
— Jr. Laravel & Backend Engineer, WorkSaar
1. Under the Hood: Persistent HTTP/2 Multiplexing & Provider Throttling
A major bottleneck in push notification dispatching is connection setup overhead. Opening a new TLS connection to Apple or Google servers for every single notification message limits throughput to a few hundred messages per second per server node.
Enterprise notification backends maintain persistent HTTP/2 connection pools. Under HTTP/2, hundreds of concurrent push notification payloads are multiplexed over a single persistent TCP/TLS pipe with zero per-message handshake penalty. Paired with localized token deduplication and batch dispatching APIs, throughput scales linearly across worker nodes.
2. Step-by-Step Architecture for High-Volume Push Dispatch
Engineers can implement a resilient, scalable push delivery engine following this blueprint:
- 1Token Ingestion & Lifecycle Management: Ingest APNs and FCM device tokens upon user login, storing them in a distributed Redis cluster paired with PostgreSQL for permanent persistence.
- 2Queue Sharding & Priority Tiers: Direct incoming messages into distinct BullMQ / Redis Streams queues based on urgency: P0 (2FA codes, live ride status) bypasses bulk marketing queues (P2 promotional sales).
- 3HTTP/2 Persistent Worker Pool: Deploy Node.js or Go worker clusters that maintain warm, authenticated HTTP/2 connections directly to APNs and FCM endpoints.
- 4Dead Token Pruning & Feedback Loop: Listen for `BadDeviceToken` and `Unregistered` HTTP/2 error responses from Apple and Google, immediately pruning invalid tokens from databases to preserve delivery reputation.
3. Technical Trade-Offs & Architectural Comparison
Comparing high-concurrency push architectures against naive synchronous notification scripts:
4. Critical Production Anti-Patterns to Avoid
Avoid these critical production mistakes when scaling mobile push infrastructure:
- Sending High-Priority Messages to Stale Device Tokens: Continuing to push to expired device tokens causes Apple and Google to throttle your server IP addresses. Promptly process APNs 410 (Gone) and FCM unregistration responses.
- Broadcasting Unsegmented Blasts Simultaneously: Triggering a 5-million-user push notification broadcast at the exact same second creates massive 'thundering herd' spikes on your own backend API servers when users tap the notification. Always jitter and rate-limit delivery over a 5-minute window.
- Putting Sensitive User Data in Notification Payloads: Plaintext push notification payloads travel through third-party servers and can display on locked screens. Send silent data pushes that trigger background app fetches from secure authenticated endpoints.
- Neglecting Time-to-Live (TTL) Configurations: A flash-sale notification delivered 6 hours late due to a queue backlog causes customer confusion. Always set explicit TTL parameters on message headers.
5. Measurable Real-World Benchmarks & Outcomes
Performance metrics achieved across WorkSaar high-scale mobile push implementations:
- Sub-2-Second Delivery for 100,000+ Concurrent Recipients: Achieved during peak promotional events and breaking alert triggers.
- 99.98% Successful Handshake Rate: Persistent HTTP/2 connection pooling eliminated TLS renegotiation dropouts.
- 45% Reduction in Database Storage Footprint: Automated dead-token pruning removed millions of inactive historical device tokens.
Engineering Challenges & Architectural Solutions
The Core Technical Challenge
Notification delays during emergency transit broadcasts and flash sales, alongside unpruned invalid device tokens causing provider rate limiting.
WorkSaar Engineering Solution
We designed a distributed worker tier using Redis streams and BullMQ, paired with asynchronous APNs HTTP/2 multiplexing and FCM topic sharding.
Technologies Deployed
Measurable Results & Business Outcomes
- Over 1,000,000 push notifications delivered in under 45 seconds during peak events
- 99.8% message arrival rate verified by client-side receipt telemetry
- Automatic stale token detection keeping device registers pristine
- Sub-100ms dispatch latency for high-priority emergency alerts
Frequently Asked Questions
Looking Ahead
Modern engineering success is not defined by adopting every fleeting technological trend, but by architecting systems that balance user delight with rock-solid operational resilience. By grounding mobile push notification concurrency fcm in disciplined event-driven patterns, scalable databases, and automated testing, your organization builds software that scales as rapidly as your business vision.
Related Case Studies & Architecture Guides
Let’s Build Future Together.
