You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Problem Overview


Summary of Proposed Solution:

My proposed solution is that notification topics are defined and potential recipients ( MFI members (Staff or Customers) ) are subscribed to a topic when their account is created. Hence, in the occurrence of an event which matches the topic, a topic mapper will provide all members who need to be notified of the event ( for an Company client account is created hence the manager of the office).


NB: Topic definitions and topic mappings are persisted into the database.


So, when an actual event occurs, the system knows the subscribers to notify and now the notification itself has to be generated. An event listener listening to the rest API controller Event emissions, will invoke the notification service


NB: each event emitter will have a corresponding listener listening to it.


The notification service will start by creating a  notification object for the event, the notification object will be persisted in to the database and later added to a notification queue for processing.


The notifications are then mapped to the list of members who have to receive them (for instance a new client created event can send out a notification to the customer (customer), the manager of the office (staff) and anyone who needs to know of an new client account) and at this stage notification which do not have to be sent are discarded based the subscriber’s priority declarations.


The notification mappings are then persisted into the database and then queued into a notification-subscriber queue for processing


The notification-subscriber queue is take and transmission begins.


To personalise the message, a subscriber’s prefered language and communication stated during account creation is used to localize and separate notifications into SMS and Emails.


A member who selected a communication channel during account creation has indicated consent to receive notification hence we have to determine how often they will receive emails to avoid spamming them.


To determine how frequent a member gets a notification, the subscribers predefine notifications they would like to receive based on three priority categories (ie during account creation a user chooses a topic and assigns High, Medium and Low priority to it ). The system will also predefined default topics which have to go out eg: (Client created, Loan created, Account Created etc).


The messages are now formatted using a template associated to a topic.


The prepared messages will be passed to the application containing email gateway such as google’s SMTP server or Twilio SMS to be transmitted. I propose that the system allows multiple configurations to accommodate cases where the application supports multiple organisations who use different services.


Data (Notification, Notification mapping, Templates, Topics, Topics mappings, Subscribers) generated will be persisted into the Microservice’s database.


  • No labels