Notification System Design

📋 Overview

A modern Notification System is responsible for delivering timely messages across multiple channels: In-App, Mobile Push (iOS/Android), Email, and SMS. The system must handle massive scale, guarantee high deliverability, and respect user preferences (opt-outs and quiet hours) while maintaining low latency for critical alerts.

---

🏗️ Core Principles & Characteristics

• Multi-Channel Delivery: Orchestrating different protocols (WebSockets for in-app, FCM/APNs for mobile, SMTP for email).
• Asynchronous Processing: Notifications should never be sent synchronously during a web request. They are offloaded to message queues to protect the user's primary journey.
• Rate Limiting & Throttling: Preventing "Notification Fatigue" by capping the number of messages a user receives per hour/day.
• Prioritization: Categorizing messages (e.g., "OTP/Password Reset" = High Priority, "Marketing" = Low Priority) to ensure critical alerts aren't stuck behind bulk mail.

---

⚖️ Trade-offs: Pros & Cons

• WebSockets vs. Push (FCM):
  • WebSockets:
    • Pros: Instant, bi-directional, very low overhead.
    • Cons: Requires the user to have the app/tab open.
  • Push Notifications (FCM/APNs):
    • Pros: Works even when the app is closed.
    • Cons: Managed by Google/Apple; delivery isn't 100% guaranteed.
• Centralized vs. Distributed Sending:
  • Pros (Centralized): Easy to manage templates and global opt-outs.
  • Cons (Centralized): Becomes a single point of failure and bottleneck.

---

🌍 Real-World Implementation

• Uber/Zomato: Use a combination of WebSockets for the live "Driver is arriving" map and FCM/APNs for "Order Placed" alerts.
• Slack/WhatsApp: Rely heavily on persistent WebSocket connections for instant chat, with sophisticated "Sync" logic to deliver missed messages when a user reconnects.
• Financial Apps: Use SMS (via Twilio) for 2FA as it's the most reliable channel that doesn't depend on data connectivity.

---

💡 Interview "Gotchas" & Tips

• The "User Preference" Problem: Always mention a Preference Service. A user might want "Order Updates" via Push but "Monthly Statements" via Email.
• Idempotency & Retries: If an email provider (SendGrid/Twilio) is down, the system must retry with Exponential Backoff. Use a unique notification_id to ensure retries don't result in duplicate emails.
• Device Tokens: Explain how you store and update device_tokens for FCM/APNs, and how you handle "Token Invalidation" when a user uninstalls the app.

---

📐 Suggested Architecture Primitives

• Notification Service: The core logic for template rendering and routing.
• Message Queues (Kafka/RabbitMQ): To decouple the app from the latency of third-party providers.
• Third-Party Gateways: Twilio (SMS), SendGrid/Mailgun (Email), FCM/APNs (Mobile).
• WebSocket Gateway: To maintain persistent connections for active users.
• User Preference DB: Stores opt-in/out flags and channel priorities.