Modern applications notify users of many events across more and more channels. This has led to notifications complicating the code-base and annoying the user. This has raised the need for software teams to take notifications seriously, as a separate Service, with its own technical and non-technical complexities and requirements.
Notification Service Definition
A notification service facilitates sending, managing and monitoring product-to-user notifications. This can include notification design, integrations for delivery, user notification preferences, and analytics. It is commonly implemented internally as a service or microservice, or externally through a Notification-as-a-Service product.
What is NOT a Notification Service?
- AWS SNS, Firebase, etc.: These are delivery mechanisms that a Notification Service would rely on. They lack the design, management and monitoring stages.
- Promotional/Marketing Tools: Tools intended for sending one-to-many notifications to multiple users at once for promotional/marketing use-cases. Telltale signs are using marketing terminology such as "Engagement," "Campaign" or "Cross-Channel".
Do I need a Notification Service?
Like with most engineering decisions, our research shows that this depends on a few factors:
- Volume and diversity of notifications
- Number of channels; e.g., email, in-app, push, SMS
- Notification controls for users (notification preferences) and for internal teams (feature-flags, analytics) - read more here
Let's look at two scenarios quickly:
Scenario 1:
Acme's Electric Bike Product has a mobile app that alerts users on "low battery". The developers need to perform:
- One (1) integration to a push notification service, e.g., Firebase
- One (1) code change to trigger the notification when the battery is low
- One (1) change in the mobile app to display the notification
- One (1) automated or manual test to ensure things work
- No real scalability concerns since "low battery" notifications are never going to be high in volume
The above tasks will result in a handful of small code commits, not requiring any significant software architecture effort.
Recommendation: No notification service required.
Scenario 2:
Acme's Stock Management Product can send 8 different notifications across 3 channels. The developers need to perform:
- Three (3) integrations, e.g., Twilio, SendGrid, Push
- Eight (8) code changes in places that require triggering the notification
- 3x8 = 24 notification UIs in the form of either email templates, front-end components, and so on
- 3x8 = 24 automated or manual tests
- For this variety of notifications, users expect to get a notification preferences management page requiring UI, APIs, and at least a database table
- The product management team expects to analyze open and click rates so they can test and improve notifications, requiring a logging mechanism and an analytics dashboard
- Notifications could be high in volume at peak hours of the stock market, thus needing some queuing mechanism
- At high volumes, your downstream APIs, such as the your email service, may suspend your account if you don't take the necessary precautions
Creating these capabilities requires more than 50 code commits all over the code-base, downstream API protection, new APIs, even requiring infrastructure such as queues and databases.
Recommendation: Create a Notification Service to encapsulate all the above.
Requirements of a Notification Service
Non-technical Requirements:
- Supported Channels. Consider: Email, In-App (bell), Push, SMS, Automated Calls, Slack/Teams
- Visual Editors for each channel so your design/customer success team can build the notifications
- Dashboard to create, modify, disable notifications without code changes
- Logging to review and debug problems
- Analytics on notification engagement to learn and improve
- User Preferences for end-users so they can change their notification settings
Technical Requirements:
- APIs
- Documentation
- Back-end Library or API Wrapper so developers can easily send notifications from anywhere in the code without studying the API
- Respecting downstream service limits to avoid getting throttled or suspended
- Retention: How far back do you want to see logs or analytics?
- Scalability: How many notifications can you reliably send per second?
- Availability, Resiliency, and Recovery
- Compliance (SOC2, HIPAA, ...)
Implementation Options
Option 1: No Notification Service
If your notifications are extremely simple and are going to stay that way in the next 3-5 years, there is no need to worry about a Notification Service. Find a 3rd-party for delivery, e.g. SES/Twilio/SendGrid, and make API calls directly.
Option 2: Notification-as-a-Service Products
Similar to how Auth0 or Cognito abstract away Authentication, we built our own Notification as a Service to abstract away notifications so you can focus on more important dev projects.
Option 3: Building Your Own Notification Service
If your notifications are extremely unique, e.g. SMS notification that also acts as a chatbot, or your channels are uncommon, e.g. Postal Mail, then you may need to create and roll out your own notification service.
What about Open-Source Notification Services?
We didn't find an open-source notification service that we would recommend for production. They are either inactive or explicitly warn against using in production.
If you find a good one, please let us know so we update this page.
Comparison
Conclusion
- If your product does not heavily rely on notifications in the next 3-5 years, implement your notifications directly without worry.
- If notifications are an important part of your product and important to your team, treat them as such and consider a notification service.
- If your notifications or channels are not extremely unique, consider a notification-as-a-service to skip all the work and worries of building a new service.
.png)
.svg){kind=small}