There is a need from many solutions to send notifications for particular events. An example would be sending an Order Invoice email to a customer when an order is created or sending an Sms notification of a tracking event i.e Order is being packed, Order shipped, Order is with the courier etc.
Development of a simple “Notification Hub” microservice, that can broker notifications of multiple types to recipients. This can be carried out in an event-driven or request-driven manner. If request driven, it can be syncrhonous or asynchronous.
The two examples of notification types are email and sms, others may be push notifications to say MS Teams or Slack. But the potential for extension to any provider type is there.
The following diagram outlines the proposed design:
- Web API - request can be made to create a notification, if valid, it will add it to the queue.
- Service Bus Queue - queue rather than topic as we don't need multiple subscribers to the same topic, we just need a single queue to work thought with regards sending notifications.
- Notification Handler - reads the messages from the queue and sends the notification types to the recipient. The scalable part of the Notification Hub - if we want to speed up processing mails, then we can scale this part of the microservice.
- Providers - integrations to provide the send functionality.
- Storage - attachments will be kept in the storage, templates (when using SMTP) can be kept in storage also.
- Secure Vault - provider credentials and azure service credentials can be stored securely in Key Vault.
- Recipient delivery - end users receiving notifications.
- User Interface - possible development of a user interface, where templates can be added and providers configured (future).
Worth noting that it is envisaged that the web API aspect will only create notification messages on the queue and not directly utilise the providers. This means that notification handler can have the singular purpose of dealing with the notification messages.
There will be multiple options for integration with providers:
- SMTP - Relay Server
- Sendgrid
- Sendgrid
- Textlocal
- Clickatel
Today we support SMTP and Sendgrid, so I suggest we start with those providers for email.
With regards Sms, we don’t do this today, so we could start by using Sendgrid, or alternatively could look at other providers such as Textlocal or Clickatel.
As mentioned above - the notification handler can be scaled independently from the API. Therefore if we need to process messages from the Notification queue quicker, we can scale up the number of instances handling the messages.
No credentials will be checked into the repository. Instead, provider credentials will be gathered from Key Vault. To access Key Vault, the applications in the Notification Hub should have MSI access. The same applies for the storage account.
TBC - this may not be needed(?)
The proof of concept will be a single application that does both the web API aspect and the event driven processing - this can later be split into two applications for the scalability needed. The code within will be segregated so it’s easier to split.
The proof of concept will only implement the Sendgrid email provider, to prove the application works as expected.
The following roadmap will show the plan for continued development of the notification hub. There are no timelines associated with this as I have no clear indiciation of how important this work is, stacked up against other work that’s going on.
