IT:AD:Design:Blueprints:Transactional Email Rule Engine
Summary
A couple of years ago, the first time I wrote one of these, I designed it poorly.
My mistake was that I was using a Windows Service to trigger an hourly scan, that would send off emails.
The design flaws were several:
- the two concepts (scanning/sending) were too tightly coupled for maintainability,
- it only worked for a while: we grew till scanning took over an hour,
- it was a pain to scan over sharded databases
These days I'd go about it differently
Notes
- Start by developing a second set of tables to keep track of metrics that are the basis of your email triggers.
- Where suitable, try to have the app push/write to these metric tables, as to what features were used when, so that one doesn't have to scan/pull for so much data.
- This is not always the right choice (writing an update to a table, for example every time they access a page (eg every 30 seconds), obviously costs more than scanning/reading for it later once every 15 minutes)
- It is maybe appropriate if the event requires a expensive join, and the app was doing it anyway.
- Most importantly, don't send the emails in the same loop. Just collect together the data.
- Have a second service read the collected data and process the summary metrics.