How do you design a multi-channel notification service supporting Push, SMS, and Email with rate limits?

A modern notification service must dispatch millions of alerts across diverse delivery rails (Mobile Push, SMS, Email, In-App) while protecting users from spam fatigue and handling third-party provider outages gracefully.\n\n### 1. High-Level Architecture Flow\n\n\n[Client Services] ──► [Notification API Gateway]\n │\n ▼\n [User Preference & Rate Limiter]\n │\n ▼\n [Priority Routing Engine]\n │\n ┌────────────────────┼────────────────────┐\n ▼ ▼ ▼\n [Push Queue] [SMS Queue] [Email Queue]\n (APNs / FCM) (Twilio) (SendGrid)\n\n\n### 2. Core Functional Components\n1. User Preferences Engine: Checks user settings in DynamoDB/Redis before dispatching (e.g., User has muted "Marketing SMS" or enabled "Quiet Hours between 10 PM and 7 AM").\n2. Rate Limiting & Frequency Capping: Enforces strict quotas (e.g., maximum 3 promotional notifications per user per 24 hours) using Redis Sliding Window counters.\n3. Priority Queues (Kafka / SQS):\n * High Priority (P0): 2FA security codes, transaction OTPs, password resets. Dedicated low-latency workers.\n * Low Priority (P1): Promotional discounts, product updates, newsletters. Workers throttled to avoid overwhelming downstream provider APIs.\n4. Provider Failover & Idempotency:\n * If Twilio experiences an outage, automatically failover to a secondary carrier (e.g., AWS SNS / MessageBird).\n * Assign each notification a UUID idempotency key to prevent sending duplicate SMS messages during worker retries.\n\n### Key Architectural Comparison\n| Channel | Latency SLA | Cost per Message | Delivery Protocol | Provider Failover Required? |

| In-App Webhook | < 200 ms | Free | WebSocket / Server-Sent Events | No |\n