Design a Push Notification Service

Problem statement

Design a push notification service that stores device tokens, manages push credentials for iOS, Android, and the web, and fans out messages in near real-time for transactional alerts (chat message, ride arriving, payment received), operational notifications (security alerts, outages), and marketing campaigns (flash sale to a 40-million-device segment). The platform must accept sends from dozens of internal product teams, evaluate targeting rules against billions of device records, respect user preferences and quiet hours, hand messages to APNs and FCM at very high throughput, ingest provider feedback, and report delivery analytics.

This is not a queue with two HTTP clients bolted on. Three properties make it a distinct system design problem.

1. You do not own the last mile

Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM) are the only roads to the device. Apple retired its legacy binary protocol and required the HTTP/2 provider API from March 31, 2021 onward; Google deprecated the legacy FCM HTTP and XMPP protocols with a June 2024 deadline in favor of the HTTP v1 API. Both providers impose their own semantics: APNs uses per-topic JWT authentication, priorities 10 and 5, collapse IDs, and returns status codes like 410 Gone when a token is dead. FCM v1 uses OAuth 2.0 service-account tokens, supports token, topic, and condition targeting, caps topic-message send rate around 3,000 QPS per project, and throttles topic messages per device. Your architecture is therefore a rate-limited adapter layer between your own event volume and two external systems whose limits you can observe but not control.

2. The write path is dominated by fan-out, not ingestion

A marketing campaign addressed to one segment becomes one row at intake and hundreds of millions of provider calls at the edge. The intake API is low-QPS and strongly consistent; the fan-out engine is a partitioned, resumable, idempotent batch machine; the provider edge is a fleet of long-lived HTTP/2 connections with per-connection flow control. Conflating these three into one service is the most common interview mistake.

3. Tokens are a living dataset

Device tokens rotate on reinstall, OS restore, and device transfer. Apple returns 410 Gone with a timestamp; FCM returns UNREGISTERED or INVALID_REGISTRATION. If you keep sending to dead tokens you waste capacity, damage your sender reputation, and on iOS you can be throttled for repeatedly targeting invalid tokens. Token hygiene — feedback ingestion, invalidation, deduplication across reinstalls — is a first-class subsystem, not cleanup work.

Public scale anchors versus design assumptions

The category is demonstrably massive. Google has publicly stated that FCM handles well over 100 billion messages per day, and Apple describes APNs as the hub delivering notifications across the entire Apple device fleet at comparable order of magnitude. LinkedIn's engineering blog describes a notification platform that digests and ranks per-member events before they ever reach the push layer. Push SaaS vendors such as OneSignal publicly report delivering billions of notifications per day across hundreds of thousands of apps, and Braze's public materials describe tens of billions of monthly cross-channel messages. These are company-reported figures used as context.

For capacity planning this answer explicitly assumes: 800 million registered devices, 200 million active devices per day, 2 billion notification send attempts per day, a 5× diurnal peak, and marketing bursts that are intentionally drained at a controlled rate rather than fired instantly. Every uncited number below is a stated design assumption.

The four architectural planes

1. Intake plane: send APIs, campaign creation, targeting validation, idempotency, quotas per sending team.
2. Fan-out plane: segment evaluation, sharded campaign cursors, per-device rendering, quiet hours and frequency caps.
3. Provider edge plane: APNs and FCM adapters, connection pools, retry with backoff, feedback ingestion, token hygiene.
4. Insight plane: receipts, analytics, A/B holdouts, delivery-rate monitoring, complaint and uninstall signals.

A strong answer keeps these planes separate: the fan-out plane can be throttled without losing intake durability, and the provider edge can degrade without corrupting campaign state.