Design a Multi-Channel Notification Service

Messaging & Event-DrivenMediumdesign-notification-service

Design a Multi-Channel Notification Service

Design one service that delivers push, SMS, email, and in-app notifications — with user preferences, quiet hours, deduplication, and third-party providers that fail independently.

FanoutTemplate RenderingRate Limiting per UserProvider Failover

Traffic & Capacity Estimates:

500M notifications/day · 4 channels · 3 providers per channel · <5s push latency

Functional Requirements

•Accept a notification intent, resolve the user's channels and preferences, and render per-channel templates.
•Deliver via third-party providers (APNs, FCM, SMS gateways, SMTP) with automatic failover.
•Respect opt-outs, quiet hours, per-user frequency caps, and localisation.
•Deduplicate and bundle related notifications rather than sending twenty in a row.

Non-Functional Requirements

•Push notifications delivered within 5 seconds of the triggering event.
•A provider outage must degrade one channel, not the service.
•Compliance-critical notifications must be traceable end-to-end with delivery receipts.

Back-of-the-Envelope Math

500M/day = ~5,800/second average, with campaign spikes to 200k/second.
Device token table: 500M devices * 200 bytes = 100 GB, read on every delivery.

Key Architectural Trade-offs

A campaign blast and a transactional 2FA code cannot share a queue — priority lanes or separate pipelines decide whether logins survive marketing.
Per-user frequency caps need cross-notification state on the send path; enforcing them centrally is correct and adds a read to every delivery.
Bundling improves user experience and delays individual notifications — the window length is a product decision disguised as an architecture one.

Click or drag a component onto the canvas, then connect the handles to draw the data flow.

3 nodes · 2 edges

Components · 35

Client & Edge4

Compute & Gateway7

Storage & Caching11

Messaging & Streaming6

Coordination & Ops5

Intelligence2

React Flow