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

Re: Architecture Proposal | Fineract CN SMS & Email Notifications


I think this is an excellent proposal.  Might it make sense to begin a
new area in confluence to begin work in a more content-managed manner?

If you have a confluence id, let me know what it is, and I'll give you
permissions, and point you to where it belongs in the current
confluence structure.

Best Regards,

On Thu, Mar 8, 2018 at 6:43 AM, Rahul Goel <rahul.usit12@xxxxxxxxx> wrote:
> 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.
> --