Design a Notification Platform

A notification platform accepts domain events, decides recipients and channels, applies user preferences, renders templates, and sends through providers such as email, push, or SMS. Separate event ingestion from delivery so provider latency does not block the originating business transaction.

Use queues, provider-specific workers, retries with backoff, rate limits, and dead-letter queues. Deduplicate by a stable notification key when duplicate messages would confuse users. Store delivery state with clear meanings such as queued, attempted, delivered, bounced, or permanently failed; a provider accepting a request does not always prove that a human received it.

Respect user preferences, unsubscribe rules, quiet hours, and tenant limits. Prioritize transactional notifications differently from marketing messages, and ensure provider failures do not cause unbounded retry storms.

Notification pipeline
Key Takeaways
  • Decouple event creation from slow provider delivery.
  • Track delivery state and deduplicate appropriately.
  • Apply consent, preferences, and rate limits before sending.
Knowledge Check

Why might a notification system use a durable queue between domain events and provider workers?