How to design notifications service system

This post is a personal cheat sheet on how to design notifications service system. Usually it’s embedded system.

Questions to ask:

• What types of notifications are we allowed to send?
• Should it be plugable (it’s easy to add new type of notification)?
• Should we build system as SaaS product or this system is only for internal usage?
• Do we need to implement notifications prioritization (multiple notifications are sent at the same time)?
• What’s expected system load?

Functional requirements:

• Send notifications
• To be plugable (easy to add new type of notifications)
• To provide saas service (you also should be able to rate limit, user should not be able to get more than 5 promotional notifications per day)
• To prioritize notifications (process high priority messages first, for example password notifications)

Non-functional requirements:

• High availability
• High load

Design overview:

Actually in case if system is small and expects low load all services can be wrapped into one monolith. But it’s not our case :)

Design overview (you can click on link to expand it)

Client 1, client 2 - clients who want to send out notifications.

Notification service - interface for clients to talk with the rest of the system. There are 2 types of requests that comes to notification service:

1. I want to send this particular message to this particular user via an email or phone number - saas product.
2. I have user id and want to send him/her a notification - for internal usage.

Notification validator & prioritizer service + Kafka - here we validate user id and content (is it empty or not, etc). As for prioritization - we track messages priority (it can be passed with payload), then based on priority we publish them into appropriate topics. Example:

• High priority:  topicA (logins) - process first.
• Medium priority: topicB (transactions) - process second.
• Low priority: topicC (promotion activities) - process third.

Rate limiter + request counter service - checks 2 things:

1. Client who’s calling me, is client allowed to call me this number of times.
2. Am I supposed to send specific users notification this amount of times.

We will have redis to track all this counters. For example: we can have composite key [user id, notification type] and count number of requests.

User preferences service - service that helps to manage user preferences. For example: don’t send me sms, send me only emails or user does not want to get promotional messages.

Preferences DB  - source of truth for db preferences (only for internal usage), 3rd parties handle it on their own side

User service - service that helps to get info about user. Then we push notification to kafka which has multiple topics. These topics are listened by multiple handlers, they consumes messages from topics (sms, email, etc…) and pass them on to specified providers that send notifications.

Vendors - services that actually send notifications, can be multiple for the same handler. For example: vendors can be different for different geo regions (sms vendor for UK, USA, Germany and etc). In case if we need to add new type of notification we just need to add appropriate business logic, create new topic, handler and vendor.

Notification tracker - service that is used for notifications audit, mostly write operation to Cassandra (99% of time).

How to implement segmented notifications?

We send the filter to Bulk notification service (users who did something in past 3 days etc) via Bulk notification UI. Segmentation service decides whom to send notifications (decisions can be made via ML models) and calls Notification service with list of user ids.

Resources:

• Notifications service system design 
• System design interview notification service 
• Notifications service design
• [Linkedin] Notifications service design  

 

Этот пост — персональная шпаргалка о том, как спроектировать систему службы уведомлений. Обычно это встроенная система.