osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Architecture Proposal | Fineract CN SMS & Email Notifications


Hi

I would like to propose my idea for implementation for *SMS & Email
Notifications Service*.

*As per my current understanding :*
This single service is responsible for preparing and delivery of SMS/Email.
MFI staff can enable notifications which member chooses when creating their
account. Apart from this, this service will contain integrations with
third-party like Twilio.
Basically this service will be responsible for campaigns, delivery of
Notifications and vendor integrations.

*What I propose :*

We should break this service into further smaller microservices as follows:

   1. *Prepare-Notification-Service*
      - This service will listen to different events and will act
      accordingly, gathering information from other microservices such as
      accounting, office, customer etc for data and validations
purposes and will
      decide which set of users to send notification, thereby selection
      corresponding notification template  and then sending request either
      single, bulk API of conveyor service or publish to specific queues whose
      consumer will be again the conveyor service.
      - In case of campaigns, this service will filter out the users to
      whom the campaign is to be targeted, preparing all the other relevant
      information required for campaign handling and in the end for
      notifications, it will talk to conveyor service
   2. *Conveyor-Service*
      - As the name suggests, this service will act as a conveyor only. It
      will talk to template service(talked about this below) for sms/email
      notification final content.
      - It will contain integration with third party vendors like Twilio.
      - If in future we consider PUSH Notifications for desktop/mobile
      devices, it will integrate that too.
      - It will control notification logs like whether an EMAIL/SMS was
      delivered or not, implement retry mechanism if required.
      - It will control which vendor to use for communication purposes. If
      for example one vendor is down for some reason, this service
will redirect
      all notifications request to some other vendor available at that time
      - It can be scaled independently if required.
      - This service basically deals with actual sending of the
      notifications.
   3. *Template-Service*
      - As the name suggests this service will be responsible for SMS/EMAIL
      templating.
      - It will talk to only conveyor-service
      - It will contain basic templates in db and will return final
      prepared template, For example
         - pre-defined template is:
         *Hi {{userName}}, your account No {{accountNumber}} has been
         debited with {{currencyCode}} {{amount}}.*
         - It will return: *Hi Rahul, your account No 123456789 has been
         debited with INR 1000.*
      - Conveyor-service will provide provide relevant payload and
      templateId as received from notification service or directly through API.
      - The final template prepared by this service will be used by
      conveyor-service to send the desired notification.
      - If we want to change the template of any type of notification in
      future then that would be possible through this service APIs without
      affecting any other service or code.

I would like to hear community member's thoughts and viewpoints on this
proposal. I am open to all kind of suggestions.


-- 
RAHUL GOEL