Design a Broadcasting Alert System

Problem statement

Design a broadcasting alert system that lets authorized admins create an urgent message and deliver it to a very large subscriber base — potentially all users — within seconds, across mobile push, SMS, email, and in-app surfaces, with delivery tracking, read receipts, and honest status reporting back to the operator who triggered it.

The trap in this question is treating it as a marketing push pipeline. A coupon campaign that trickles out over an hour is fine. An alert announcing a regional outage, a severe weather event, or a security incident that arrives late, arrives twice, or silently drops for 4% of users is a trust failure and possibly a regulatory one. The design therefore separates alert priority classes and gives the emergency lane resources it never shares with bulk traffic.

Why the problem is distinctive

Three properties make broadcasting different from one-to-one messaging:

1. The write amplification is one-to-millions, triggered in a single instant. One admin action becomes hundreds of millions of provider calls within a minute. No queue sized for steady state absorbs that without explicit partitioning, batching, and backpressure.
2. The fan-out target is a moving set. Devices register and deregister, tokens expire, users opt out, time zones matter. The system needs a deterministic targeting snapshot so the operator can later answer 'who was this sent to and who was missed'.
3. Delivery is not under our control. Apple APNs and Google FCM are best-effort transports; SMS providers throttle by campaign throughput tiers; email can land in spam. Guaranteed reach requires an in-app store-and-forward inbox plus a fallback ladder, not faith in a single channel.

Real-world anchors

National alert systems prove the category is safety-critical. In the United States, FEMA's Integrated Public Alert and Warning System (IPAWS) distributes Wireless Emergency Alerts over cell broadcast, geo-targeted to cell towers, with no phone number required and no opt-out for presidential alerts. Japan's J-Alert has used satellite distribution to municipalities since 2007, and the Netherlands' NL-Alert and the UK Emergency Alerts service use cell broadcast as well. These systems exist because commercial channels alone cannot guarantee reach during congestion.

At the commercial scale, WhatsApp publicly reported passing 100 billion messages per day in 2020, which is roughly 1.16 million messages per second on average, and its sent/delivered/read acknowledgment ladder is the direct ancestor of the receipt model used here. Telegram publicly reports hundreds of millions of monthly users and built broadcast channels with effectively unlimited subscriber counts by storing a channel message once and referencing it per subscriber. Twitter's engineering team described hybrid fan-out — precomputed timelines for typical users, read-time merge for accounts with millions of followers — which is the exact structural decision this design faces for segments.

The four architectural planes

1. Authoring and governance plane: drafting, targeting preview, approval, scheduling, cancellation, audit.
2. Fan-out plane: segment expansion, priority partitioning, batching, provider dispatch, retry and fallback.
3. Delivery and receipt plane: device inbox sync, acknowledgments, open/click events, provider status webhooks, reconciliation.
4. Observability and learning plane: per-alert funnels, provider health, error budgets, incident evidence, channel effectiveness.

A strong answer keeps these planes separate. The fan-out plane must never block on analytics, the receipt plane must never gate dispatch, and the governance plane must be able to cancel an in-flight alert without corrupting the ledger.