Building a scalable, provider agnostic email service
Deskera platform sends email notifications to users on various events. Each product use a different methodology to do similar actions—and we found ourselves spending appreciable effort in the integration of these services.
As we evolve as a product the number of events increase — and each application and services use different providers to send these emails.
The idea of this write up is to define a microservice that can address all the above problems.
Design Considerations:
- Support for existing and new events
- Support for any provider.
- Should be easily extensible to support new providers
- This service endpoint are never exposed external world and can be anonymous
- Tenant id, User id should be passed in API payload
- Ability to control the domains where email can be send, specially useful for QA and Dev env.
Analysis: The providers use the following information to send an email
- TO/CC/BCC addresses
- FROM and REPLY_TO address
- Template Name (AWS SES) or Template Id (SendGrid)
- Payload — JSON or map (key-value pair) substitutions.
Architecture:
This design takes care of scalability of the notification service as these are deployed on k8s cluster and configured to scale in the event there is a built up of too many notifications
Implementation:
Open closed Principle has been followed to ensure that new provider implementations can be created without modifying existing one.
Factory pattern is utilised to take care of instantiation of the right provider to send the email.
Logging
All events that are coming to Notification Service are logged for audit purpose.
Conclusion
This is first version of notification service which caters to all the use cases that we have seen so far across applications be it ERP, GO, E-Leave, CRM etc..
Upcoming — In the near future we would need an upgraded/evolved design to cater to Marketing needs where we run campaigns so on so forth.
