I have a web application that has a lot of multi-action items that are done that require an email notification. Although not the biggest deal, we currently have it set so that it sends an email to the other user when things like a comment or a "status" has changed.

Let's say our one user adds a comment and then changes the status of this post to "Under Review", at this point, the other user is being notified by email twice about seperate actions that have taken place. This is under a light scenario, if more actions were to take place, it would send many more emails. I feel like this could easily be marked as spam in certain inboxes.

What system can be used to wait a certain amount of time in order for all actions to take place?

  • 1
    Maybe instead of sending emails right away, write a database entry per notification, and have a job on a 5 minute timer that grabs all the notifications from this data structure for a given single email address and bundles them into a single email.
    – GHP
    May 24, 2021 at 20:31

3 Answers 3


Providing users with the right notification at the right time, requires need a user-centric approach. The first thing you’ll need is not a solution, but to think about the requirements:

  • does a user need to be informed immediately?
  • is a user interested in all the details of every change or is a summary of the most important changes sufficient?
  • is the user interested in having the content in the notification or is it sufficient to tell there was a change and user would anyway consult the record?
  • could the notification email regroup asynchronously several changes? if yes, at what rhythm (hourly? daily? weekly?) and how should data be regrouped in the message (chronological? chronological per type of records? chronological per record?) should the email show a list of all the changes in a period regrouped
  • do all users need the same frequency of notification? or may the user expect to choose him/herself the rythme (e.g sharepoint does) ?

To cope with all these requirements in a flexible way, you need to:

  • decide what events shall be notified, and add in your design something to keep track of the information to be notified (notification events).
  • design a notification engine with the logic that will generate the notifications based on the notification events, grouping and filtering the events at user-defined periodicity.
  • design the delivery logic for the notifications generated. Now you have email. Maybe in future you’d have also SMS, voice bot over phone or push in an app.

Finally, there synergies to be considered with other features (e.g. change log or audit trail).


You will need to separate the concept of a "notification" from the individual changes that were made. Instead, think of this notification as being composed of a summary of changes. The notification should only be sent at the end of the transaction or use case.

How you model this collection of changes depends on what kind of flexibility you need in the look and feel of the email. When in doubt, start out simple with just a key-value store like a dictionary or hash table. The data model of the email would contain this collection of changes in addition to information like the sender, recipients, etc.


You need to do 3 things

  1. Redesign your notification template to accommodate multiple notifications
  2. Persist a state change that needs a notification, with a flag saying not sent
  3. Send notifications when appropriate (time delayed, scheduled, paired, whatever is appropriate for your use case), flagging notifications as sent.

There is no ideal way to do any of those 3 things, it will depend upon your tech stack and how you want it work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.