Part 6 · 2 chapters · ~12 min

Notifications at Scale

An event-driven notification platform with preferences, templates and locales, deduplication, per-user rate limits and digests, per-channel queues with provider fallback, and delivery feedback.

Brief, questions and numbers

the brief

Every product team needs to notify users by push, SMS, email and in-app inbox, reliably and without spamming them.

question	answer we assume
volume?	100M notifications/day, spikes 20× during campaigns
channels?	push, SMS, email, in-app
critical types?	security and transaction alerts within seconds
cost?	SMS is expensive per message
compliance?	opt-outs honoured immediately

code

average    = 100M/day ≈ 1,160/s; campaign spikes ≈ 25,000/s
SMS share  = 10% → 10M SMS/day: cost and provider rate limits dominate
inbox      = 30-day retention × 100M/day × 500 B ≈ 1.5 TB

NOTIFICATIONS AT SCALE

events in, preferences and templates applied, channels out, with deduplication and rate limits

swipe the figure sideways, or tap expand for full screen

1/5

events in

Services emit domain events; the notification service decides who should be told what. Producers never call SMS providers directly.

domain events, not direct sendsone place owns user messaging

v1, the break, and v2

v1. Each service calls the SMS and email providers directly from its own code when something happens.

The break. Duplicate sends on retries, no global preferences or quiet hours, no protection from a bug looping sends, provider outages failing user flows, and marketing bursts delaying security alerts.

v2. A central notification service consuming events, applying preferences and templates, deduplicating by event id, rate-limiting per user, separate priority queues per channel (critical versus bulk), provider fallback, and delivery feedback.

the sentence

v2 buys consistent, safe and observable messaging with priorities, and pays with a central platform every team now depends on.