Notification Service

The Notification Service serves as the primary interface for initiating notifications, catering to requests from both external applications and internal systems.

• Transactional Notifications: e.g., password reset emails.
• Promotional Notifications: e.g., discount offers.
• System Alerts: e.g., downtime warnings.

Each notification request is validated to ensure completeness, requiring details such as:
Recipient’s ID, Notification type, Message content, Delivery channels (e.g., email, SMS)

Notifications intended for future delivery are coordinated through the Scheduler Service.

After processing the request, the Notification Service pushes the notifications to a Notification Queue (e.g., Kafka or RabbitMQ).

User Preference Service

The User Preference Service enables users to manage their notification preferences, determining how and through which channels they receive notifications.

The service stores and retrieves individual user preferences, allowing users to opt into or out of specific types of notifications.

Example: Users can choose to opt out of receiving marketing or promotional content.

To avoid overwhelming users with notifications, the service enforces limits on the frequency of certain types of notifications, particularly promotional messages.

Example: A user may receive a maximum of 2 promotional notifications per day.

Scheduler Service

The Scheduler Service manages notifications that need to be sent at a specific future time. These include reminders, promotional campaigns, or other notifications that are time-sensitive and not sent immediately.

For example, a promotional message could be scheduled for delivery next week.

When the scheduled time arrives, the Scheduler Service retrieves the notification from its storage and sends it to the Notification Queue for delivery.

Notification Queue

The Notification Queue, built using Kafka, acts as a buffer between the Notification Service and the Channel Processors. It decouples the submission of notification requests from their delivery, improving scalability and efficiency during high-traffic periods.

• Email Notifications: Email Topic Includes messages like password resets, promotional offers, and system updates sent via email.
• SMS Notifications: SMS Topic Short, urgent messages such as alerts or transactional updates delivered directly to mobile devices.
• Push Notifications: Push Topic Real-time updates or promotional messages sent to users' mobile or desktop devices.
• In-App Notifications: In-App Topic Notifications displayed within the application, such as user-specific alerts, updates, or promotional content.

These topics allow each Channel Processor to focus on consuming messages relevant to its channel, reducing complexity and improving processing efficiency.

• Scalability: Handles large volumes of notifications seamlessly, especially during peak traffic.
• Message Delivery Guarantees: Kafka offers configurable delivery options:
• At-Least-Once Delivery: Ensures each notification is sent at least once, with rare chances of duplicates.
• Exactly-Once Delivery: Ensures each notification is sent exactly once, eliminating duplicates and maintaining reliability.

Channel Processors:

Channel Processors handle the delivery of notifications by pulling them from the Notification Queue and sending them to users through specific channels like email, SMS, push notifications, or in-app messages.

Each channel processor acts as a consumer to the queue and responsible for consuming its own messages:

• Email Processor pulls from the Email Topic and send mail using email provider (e.g., SendGrid, Mailgun, Amazon SES).
• SMS Processor pulls from the SMS Topic and send SMS using SMS provider (e.g., Twilio, Nexmo).
• Push Processor pulls from the Push Topic and send push notification using Uses services like Firebase Cloud Messaging (FCM) for Android or Apple Push Notification Service (APNs) for iOS.
• In-app Processor pulls from the In-app Topic and sends the in-app notification via WebSockets or long polling to the user’s active session.

They work independently from the Notification Service, allowing notifications to be processed asynchronously and scaled separately. Each processor is dedicated to its channel, ensuring reliable delivery with features like retry mechanisms and efficient error handling.

Database/Storage Layer

The Database/Storage layer handles and organizes large amounts of data related to notifications. This includes notification content, user preferences, scheduled notifications, delivery logs, and metadata.

The system uses different types of storage to meet specific needs:

• Transactional Data: Structured data like notification logs and delivery status is stored in relational databases such as PostgreSQL or MySQL.
• User Preferences: Large-scale user-specific data, such as preferences and rate limits, is stored in NoSQL databases like DynamoDB or MongoDB.
• Blob Storage: Notifications with large attachments (e.g., emails containing images or PDFs) are stored in services like Amazon S3.

Monitoring and Delivery Confirmation:

Each Channel Processor waits for a response from the external provider:

• Success: The message was successfully delivered.
• Failure: The message could not be delivered (e.g., due to network issues or incorrect addresses).

The Channel Processor records the status of each notification in the notification_logs table for future reference, auditing, and reporting.

• Centralized Logging: Use tools like ELK Stack or Prometheus/Grafana to collect logs from various components and monitor the health of the system.
• Alerting: Set up alerts for failures (e.g., notification delivery failure rates exceed a threshold).
• Metrics: Track metrics like success rate, failure rate, delivery latency, and throughput for each channel.

If a notification fails to be delivered due to a temporary issue (e.g., third-party service downtime), the system will try to send it again.

The retries are done using an exponential backoff approach, meaning each retry is delayed by a longer time than the previous one.

If the notification still can't be delivered after several retries, it will be moved to a Dead Letter Queue (DLQ) for further action.

Administrators can then check the messages in the DLQ and decide whether to manually reprocess them.

Caching:

Implement caching with solutions like Redis or Memcached to store frequently accessed data, such as user preferences.
Caching reduces the load on the database and improves response times for real-time notifications by avoiding repeated database lookups.