Notification System — Notes

Functional

• Multi-channel: push (iOS/Android/Web), SMS, email, in-app.
• Personalized template rendering.
• User preferences, opt-in, quiet hours.
• Throttle frequency (no spam).
• Track delivery, opens, clicks.

Non-functional

• 100M+ users; 1B+ notifications/day.
• TXN delivery latency < 5 s; promo < 1 hr.
• 99.9% delivery for txn.

Capacity

• 1B/day → 12k/s avg, 100k/s peak.
• Per notification: 1–2 KB payload + 0.5 KB metadata.
• Storage (history 90d): 1B × 90 × 2KB = 180 TB.

API

POST /notify
{
  user_id, event_type, channel?, priority,
  template_id, params{}, idempotency_key
}

Schema

• users(id, locale, tz)
• device_tokens(user_id, platform, token, last_seen)
• prefs(user_id, channel, enabled, quiet_start, quiet_end)
• templates(id, version, channel, locale, body)
• history(user_id, ts, channel, status) (Cassandra)

Trade-offs

• Fan-out at send vs at read: notifications usually fan-out at send (push to device).
• One queue per priority vs single queue with priority field — split is simpler.
• Provider lock-in: use abstraction layer; APNs and FCM behave differently for receipts.
• Order: typically not required; per-user ordering optional (use partition key = user_id).

Refs

• Pinterest "Notification platform" blog, Uber/Lyft notification posts, AWS Pinpoint architecture, Twilio Notify, Braze, OneSignal docs.