Notification System
Blog / Notification System
Overview
Introduction
- A notification system is a system that provides a means of delivering a message to a set of recipients.
- There are many different channels notifications can be delivered through including Email, SMS, iOS, Android and many others. Nowadays notification systems are commonplace, (e.g. placing and order on Amazon and receiving an email confirming the order has been placed).
Requirements
- Functional Requirements
- Send notifications to different channels (Email, SMS, iOS, Android)
- Extendable (ability to add more notification channels)
- Non Functional Requirements
- High availability
- High scalability
- Reliable (no notifications are lost)
- Not covered
- Bulk sending of notifications (e.g. for all users that match a specific criteria)
Data Model
This is a basic outline of some of the core tables that could be included in a notification system data model.
- users
- Contains information related to the user.
- device_settings
- user_id: Foreign key which is used to identify which user to which the notification was sent.
- device_token: The token which is used to enable the pushing of notifications to different services (e.g. FCM, APNs)
- notification_channel: The channel which the settings belong to (e.g. email, SMS etc.)
- is_active: Whether a user has consented to receiving notifications for that device.
- notifications
- user_id: Foreign key which is used to determine which user is associated with the notification.
- blueprint_id: Foreign key which is used to determine which blueprint is associated with the notification.
- notification_blueprints
- content: The actual contents if the notification (e.g. HTML, plain text, JSON etc.)
- channel: The channel which this blueprint is intended to be sent to (e.g., email, SMS etc.)
To support bulk notifications a table user_notifications could be added to create a many to many relationship between users and notifications.
Basic Implementation
- Notification Sources
- Notification Sources are the upstream services that trigger notifications and can include internal services, external services, scripts, and cron jobs.
- Load Balancer
- Ensures that requests are distributed evenly among the Notification Handler servers.
- Notification Servers
- The servers will check the device_settings table to ensure that a user has consented to receive notifications in this channel. Given the relational nature of the data this database could be implemented with an SQL database.
- Rate limiting can also be implemented here with a cache like Redis for each user to track how many notifications of each type they have been sent. Rules can be configured to improve the user experience (e.g. a user can receive a maximum of only two promotional marketing notifications per day).
- Notification Queues
- If a user hasn't consented to receiving notifications on that channel, the system can stop processing the notification.
- If the user has consented, the system can then push the message onto the relevant queue based on the associated channel.
- This can be implemented with Kafka or Amazon SNS, or Pub/Sub in Google Cloud Platform.
- In this system we will use Kafka and to prevent duplicates during retries, Kafka offers an idempotent producer feature. When enabled, the producer ensures exactly once delivery to a Kafka topic, even across retries.
- Notification servers are the producers and each topic corresponds to a specific channel.
- It is easy to add new topics to Kafka which makes the system extendable for adding channels in the future as the system evolves.
- Lightweight Handlers
- The lightweight handlers act as the consumers and pull messages off their designated topic. These could be implemented with AWS lambda functions or Google Cloud Platform Functions.
- Each lightweight handler will query the notification cache and database to get the blueprint associated with the notification. The notification can then be sent onto the relevant third party service.
- If message processing fails, the lightweight handler can either retry immediately or reset the offset to reprocess the message later. Commit strategies (automatic or manual) and policies (e.g. at least once, at most once, exactly once) influence how and when offsets are committed.
- Exponential backoff is a strategy used in computing to gradually and adaptively increase the waiting time between retries of a failed operation, with the goal of reducing the load on the system and increasing the likelihood of success in subsequent attempts.
- A dead-letter queue (DLQ) could be implemented for messages that can't be processed after several attempts, a common pattern is to redirect these messages to a dead-letter queue, a separate Kafka topic can be created where failed messages are stored for further investigation or reprocessing.
- Third Party Services
- For iOS and Android notifications they can be sent to Apple Push Notification Service (APNs) and Firebase Cloud Messaging (FCM) respectively.
- For email notifications, using third party services like MailChimp or MailJet is a good option as they handle many common issues when trying to send emails at scale include implementing authentication protocols such as Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC), as well as reputation management and IP warming, which ensure that emails are actually delivered and not marked as spam. They also include other tools like audience segmentation and analytics so the system will be able to see which notifications users are actually viewing.
- For SMS notifications, using third party services like Twilio is a good option as it again handles the infrastructure to ensure SMSs are actually delivered and will also provide monitoring and analytics to see which SMS notifications are performing well.
Advanced Implementation
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo.
Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet.
Additional Discussion Points
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo.
Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet.
Master System Design Interviews
Get ready for the exact system design questions top tech companies are asking right now. Read comprehensive editorial write-ups and practice with our AI whiteboard that simulates a real, step-by-step interviewer experience.
See All System Designs →