Do you need a notification service?

Is it ok that you are calling SendGrid APIs directly? Or do you need to create a Notification Service? How about a Notification-as-a-Service product? Learn more here

Engineering
 — 
15
 Min read
 — 
November 22, 2022

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?

  1. AWS SNS, Firebase, etc.: These are delivery mechanisms that a Notification Service would rely on. They lack the design, management and monitoring stages.
  2. 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

No Notification Service Internal Notification Service Notification-as-a-Service
Time Investment
Hours - Days Weeks - Months Minutes - Hours
Monetary Investment $0 Dev Salaries, $5000-$20000 Tiered Subscription, $0-$500
Supported Channels Few Many Many
Non-Technical Features (Dashboard, Editors, Analytics)
None Maybe Feature-rich with extensive roadmap
Technical Features (APIs, SDKs, Docs)
N/A Internal Maintained APIs, Docs, SDKs
Scalability & Reliability Unknown
Unknown SLA
Code Ownership Yes
Yes No
Ideal for: Products that will never need more than a few simple notifications. Products that need unique notifications, e.g. SMS chatbot or Postal Mail notifications, with large engineering teams Products that need multiple notifications/channels with a small-mid sized engineering team

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.

Decision Tree for Notification Services

Like the article? Spread the word