5

My App has a single multipurpose Platform Event called MyEvent__e which is emitted by MANY publishers and for MANY Topics.

Receivers and subscribers need to subscribe to the event type and then do filtering on the Publisher (a String) and a Topic (and URL-like String) to find out if they actually want to handle a specific event.

My naive train of thought was to just let different purpose-specific flows or Apex Event Triggers (Handlers) do that but then someone said: "No you need a centralized Router. Otherwise it's super inefficient".

I tried it out and actually build one. But it just add complexity and syntactic sugar, but for a given complex matching I never gets better than ExD (for each event asked each subscriber if its relevant for it).

So my questions are:

  1. Do I need central routing for Generic Platform Events?
  2. Why or why not?
  3. If you recommend it how does that handle 1001 Flows that bypass my central router?
  4. Are there published best-practices or even Open-Source Apex routers?
Improve this question
8
  • It's hard to tell based on the information given how much overlap there might be between subscribers. Maybe some high level examples of what they do would help tie it together. To me, that's a core aspect of the solution space.
    – Adrian Larson ♦
    Commented May 6, 2021 at 15:39
  • I'm sure there will be a super answer soon, even for the given limited information. But I'm happy to answer specific questions.
    – Robert Sösemann
    Commented May 6, 2021 at 15:41
  • ^ That was my question. How much overlap is there between subscriber logic?
    – Adrian Larson ♦
    Commented May 6, 2021 at 15:43
  • 1
    Scenario: one event, multiple unmanaged/uncontrolled apex triggers (one from your app, others from subscribers). We don't care the order in which subscribers process a single event. My question is, if a single subscriber fails (excepts), does processing of events move forward with new events for all other subscribers? For a single subscriver an uncaught expection causes "the train" to stop for the apex handler (i.e. next batch of new events are not processed until recovery/success) afair. What's the behavior when there are multiple apex subscribers working on the same event stream?
    – MLucci
    Commented May 13, 2021 at 18:39
  • 1
    Maybe I'm not seeing something (smt in the documentation, or smt obvious) and my question has a simple answer, I think it connects with your original topic and question around if/why/which event handler architecture to choose. Thank you for coming back with a reply 🌻
    – MLucci
    Commented May 13, 2021 at 18:43

2 Answers 2

Reset to default
4

There's almost certainly no need to unify your subscribers. For some use cases it may offer benefits, others not so much, but either way the lack of a unified subscriber or handling pattern is extremely unlikely to be detrimental to the point of crashing the system, and may actually perform better in the long run.

Especially when publishing some sort of ubiquitous event from a managed package where you really don't care how the event is handled, pushing for one consolidated way to handle the events seems to offer few benefits and more headaches. It's one of the advantages of the pub/sub model that you don't have to have any knowledge of or interest in how the subscribers work to use it effectively. I would push back and ask for more compelling arguments from your colleague before considering it.

Improve this answer
1

Likely not as Salesforce have a filtering pilot in Summer '21. I would note the restriction though that this is for CometD subscribers only in the pilot. Hopefully Apex will be included when it goes GA.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .