Design a Notification Service - Push, Email, SMS

When you ask for notifications, do you mean accepting a send request, handing it to a provider, reaching a device, or a user actually reading it? I would establish that vocabulary first. Our system can own durable intent and attempts, but external delivery is only observable to the extent the channel reports it.

I accept a request only after durable intent. A successful API response means accepted, not delivered. I keep sensitive details out of lock-screen payloads and require authorization when the app fetches the underlying content. Policy rules for message categories need product and compliance review; a priority flag is not permission to bypass consent.

I use a 5x peak on a 120M-delivery daily workload. Retries, multiple devices and audience expansion can amplify that, so I would measure those distributions rather than multiply only the user count.

The deduplication boundary is business intent plus recipient plus channel, not a randomly regenerated worker request ID. If a campaign intentionally sends another message tomorrow, that is a new intent. Attempts reuse the delivery identity even when a worker or provider adapter restarts.

The external API never lets a tenant send arbitrary templates to another tenant’s users. A provider callback is an untrusted input until its signature, timestamp and account binding are verified. I store receipt evidence before deriving status.

I separate intake, audience expansion, channel queues, provider adapters and receipt processing. That lets SMS throttling or a push outage leave email and in-app delivery operational. The authoritative ledger connects these asynchronous stages.

Imagine an order shipment notification. The order service provides a stable shipment-event ID and a template version. We persist that intent once, then create a delivery for each allowed recipient/channel combination. A retry of the order event must not create a second shipment notification.

Before calling the provider, the worker validates the current lease, expiry and suppression. To make unsubscribe acknowledgment meaningful, I define the ordering point: preference update versus dispatch authorization is serialized in a per-user authority or transaction. A send already authorized may still be in flight; we cannot recall a delivered SMS.

The dangerous burst is often a campaign expanding to millions of recipients, not the intake rate. I throttle expansion according to downstream capacity and oldest eligible age. Adding workers cannot exceed a provider’s quota or make delayed transactional messages useful again.

My dashboard separates accepted-to-eligible, eligible-to-provider and provider-to-receipt latency by category and channel. It includes oldest nonexpired task, unknown outcomes, suppression rate, callback verification failures, bounce/complaint rates and per-provider cost.

I own durable notification intent, unique recipient/channel expansion and an auditable attempt lifecycle. Providers own the next delivery hop, and users own whether they read the content. I expose those distinctions rather than compressing every stage into a misleading sent flag.

I would finish by testing duplicate business events, a provider timeout after acceptance, unsubscribe during a campaign and out-of-order callbacks. These cases reveal the correctness boundary more effectively than a successful single email demonstration.