This is a general design question on how to structure trigger files for platform events. Say I publish a platform event "lead created"
and I want to do several distinct things within the same Salesforce org that published the event. I know the way that Salesforce "subscribes" to this event is via a trigger on the pEvt. I'm thinking the design should be multiple trigger files (one for each "subscriber") when processing the event via apex instead of the "one trigger per object" rule with custom objects. The thinking is that each trigger file is actually a distinct subscriber to the event and so should be separated out appropriately. This also means logic would be written within the trigger, which should be fine since the only phase that is supported is 'after insert'. Most trigger frameworks take care of working with the different phases which doesn't apply to pEvts.
I'd like to know if this design makes sense and if anyone else has implemented a platform event design where the "subscribers" are actually within the same Salesforce org that published the event.
Best Answer
This is interesting, I quickly wrote 2 triggers on a platform event. And when I fired them I could see 2 debug logs, saying both triggers were own transaction.
Both being own transaction means, they get own set of limits. Also as both are the async process you genuinely don't care about the order of execution.
I have made architecture where we split our process via events and subscribe via triggers, but never tried something like having 2 triggers on 1 event.
I believe you can do this when you wanna make a couple of complicated processes independent of each other. Having multiple subscribers to same event do makes sense in my opinion.