Confluence Id : [email protected] On Thu, Mar 8, 2018 at 4:18 PM, Myrle Krantz <[email protected]> wrote:
> Rahul, > > 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, > Myrle > > > On Thu, Mar 8, 2018 at 6:43 AM, Rahul Goel <[email protected]> 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. > > > > > > -- > > RAHUL GOEL > -- RAHUL GOEL +91-9873124753
