Publishing the event to both is definitely an option, unless there’s a large amount of traffic and another option should be chosen. I have a sample set up for this which you can find here: https://github.com/dvdstelt/priority-queues
The thing is, you’re not clear on the “condition” that you mention. Theoretically we don’t recommend content-based-routing. We recommend a sender is not aware of different receivers and when it should select on or the other to send a message.
If there is a large amount of traffic and you don’t want every message to end up at two endpoints because of performance (I/O) issues, there are other options.
One thing is to have the sender side select where the message should go. Which couples that sender to the receivers in that it has too much knowledge.
Another option is that the receiving side has a very small component where it knows about itself and its own receivers. That component is a library that you can deploy anywhere. You could even deploy it on the sender side. Using some sort of interface and scanning assemblies using reflection, the sender could verify which implementations for that interface there are. And instead of actually sending messages to 2 (or more) locations, call out to the implementations. It’s the exact same thing as the priority queues example, except the selection happens before the actual message sending happens.
This might sound exactly like option A, but the difference here is that you can modify the sending of messages, without modifying the sender. It’s just re-deploying the small component(s) and it works. So the responsibility (and code) is still with the team that actually processes that messages, but deployment looks a little bit different.