I find there is some insight in the observation at the top that events “trigger actions” and they “carry data” and that these two different roles need to be respected.
In fact, I have some design issues right now within my organization where there is a conflict between some groups who mandated that events always contain exactly all the fields within the domain, and others who complain that (1) this means there isn’t a field telling “what happened” and (2) that makes everything slow because it must go to several different systems to collect all of that data.
I have been making the argument that the single contains-all-the-fields event was impractical; perhaps I should instead have been making the argument that there are two separate use cases, and for the “trigger action” use case we should have fewer fields.
Notice that this is DIFFERENT from what Lutz Hühnken (the author of the piece) concludes. He concludes that you should reach a happy medium: include the trigger information plus whatever “wider” data is easy. My own takeaway is you should have two events: a trigger event and a wide event. (And, of course, feel free to skip either one if it won’t actually be needed.)
This is awesome feedback, thanks! Learning that a) others have similar experiences and b) came to other (maybe better?) solutions alone was worth writing it down.
I’m lazy and make Postgres handle all my event notifications using LISTEN/NOTIFY and send only the table name and primary key. Then it is up to the listener to go fetch data if it wants. We have an audit log table in the DB(via triggers), so if you need to know what changed, it’s easy enough to go look it up.
Which I guess would be the narrow view, from your perspective, though to get the wide view it’s ridiculously easy.
I find there is some insight in the observation at the top that events “trigger actions” and they “carry data” and that these two different roles need to be respected.
In fact, I have some design issues right now within my organization where there is a conflict between some groups who mandated that events always contain exactly all the fields within the domain, and others who complain that (1) this means there isn’t a field telling “what happened” and (2) that makes everything slow because it must go to several different systems to collect all of that data.
I have been making the argument that the single contains-all-the-fields event was impractical; perhaps I should instead have been making the argument that there are two separate use cases, and for the “trigger action” use case we should have fewer fields.
Notice that this is DIFFERENT from what Lutz Hühnken (the author of the piece) concludes. He concludes that you should reach a happy medium: include the trigger information plus whatever “wider” data is easy. My own takeaway is you should have two events: a trigger event and a wide event. (And, of course, feel free to skip either one if it won’t actually be needed.)
This is awesome feedback, thanks! Learning that a) others have similar experiences and b) came to other (maybe better?) solutions alone was worth writing it down.
Thanks. I appreciated the article.
I’m lazy and make Postgres handle all my event notifications using LISTEN/NOTIFY and send only the table name and primary key. Then it is up to the listener to go fetch data if it wants. We have an audit log table in the DB(via triggers), so if you need to know what changed, it’s easy enough to go look it up.
Which I guess would be the narrow view, from your perspective, though to get the wide view it’s ridiculously easy.