Email Notification Architecture Considerations

Question

We strive to develop an email notification service where emails can be scheduled daily, weekly or hourly based on certain actions that occur in our system (User Registration) or summary emails sent every Friday, for example.

What is the best way to handle duplicate emails not being sent? We thought that perhaps the application is writing the queue when a system action occurs, but this seems to have another error. Or maybe just creating all the data-driven notifications, for example, select all users where the created in the date is more than now. But in this scenario, we need a way to make sure that the service is started again, duplicate letters are not sent.

any ideas would be great!

Answer 1

My 2 cents

1) Queues. Queues are great for tasks in which you want to have a single-entry, single-output architecture type. Queues shut down systems and allow you to load system balance. They are usually used with several workers at the same end. You simply add (maybe many) messages to the queue, and then do a massive debase. IMO, which is irrational memory and resource consumption.

2) Data managed through users . It is much easier to implement, but for each notification you will check each user and put a lot of load on db.

3) Data managed through UserNotifications . In addition, you can create a separate UserNotifications table, where each user will be added after registration. It is much easier to select the right users within the given time frame, and you do not store them in memory. After sending the notification, the user is deleted from the UserNotifications table.