Notification Delivery Platform

Summary

A multi-channel notification delivery architecture that accepts upstream business events (order placed, payment received, comment posted, threshold alert triggered) and routes them to per-channel delivery workers (push via FCM/APNs, email via SendGrid, SMS via Twilio, in-app via WebSocket). Kafka carries raw business events from upstream producers. RabbitMQ handles per-channel fan-out with separate exchanges and queues per delivery channel, isolating email queue backlog from push notification delivery. PostgreSQL provides durable notification state tracking (sent, failed, bounced, suppressed). Redis enforces per-user rate limiting (notification frequency caps to prevent fatigue) and stores deduplication tokens to prevent duplicate sends across retry attempts. The inbox pattern on the consumer side ensures idempotent delivery even when Kafka produces duplicate events.

Problem Statement

Notification platforms sit at the intersection of two competing failure modes: under-delivery (critical transactional notifications: password reset, payment confirmation: must never be silently dropped) and over-delivery (marketing and engagement notifications must be rate-limited to prevent user fatigue and spam classification). The delivery path traverses external provider APIs (SendGrid, FCM, Twilio) that each have their own rate limits, availability SLAs, and failure modes. A provider outage triggers retry storms that can exhaust retry budgets for legitimate delivery attempts. Deduplication is mandatory : at-least-once Kafka delivery combined with upstream event retries means the same notification may be triggered multiple times; sending a duplicate password reset SMS is a security and trust incident.