Design a Notification System
Deliver email, push and SMS with preferences, retries and honest delivery status.
Backend and product engineers designing software behavior.
Your approach: Use diagrams, tables or prose for customer contracts, state transitions and data ownership; include APIs only to the depth the question requests.
The problem
Design a notification service for transactional and optional messages across email, push and SMS. Follow a request from acceptance to a visible delivery status, respecting user preferences. Explain retries, duplicate provider callbacks and how an urgent message avoids waiting behind a large campaign.
- Accept 10 million notification requests/day, with peaks of 10,000 requests/second.
- Each request can target several channels; providers can throttle, time out or send duplicate callbacks.
- Users can opt out of optional messages, and transactional security alerts have higher priority.
Work within these constraints
Declare p95 time from durable acceptance to the first provider attempt under normal provider operation.
Required target: ≤ 30 seconds
Define when preferences are checked and how queued optional messages honor a later opt-out.
Separate accepted, attempted, provider-acknowledged and delivered states without promising exactly-once delivery.
What to deliver
Request and status contract
Define identity, recipient, channel, template version and observable states.
Delivery pipeline
Show preference checks, durable queues, provider adapters and priority handling.
Retry and deduplication
Trace a timed-out send followed by a late callback and a client retry.
Capacity and operations
Size peak acceptance and worker demand; explain provider quotas, dead letters and sensitive-data retention.