This is a bit of general question because it would apply not only to my scenario (with Azure Service Bus) but to any event bus in the context of publish/subscribers with events.
The question is: Is there any preference towards having an architecture/topology where topics must not be shared between producers? In other words: one topic per event producer VS one topic shared across multiple producers?
I have one clear preference: One topic should be owned and accessed only by one producer and if other producers. But I seem to be the only one in a team with this opinion, while others don't seem to have any problem in sharing the same topic between different event producers "for simplicity", and I cannot really argue in terms of technical viability..
I am hoping to find valuable answers and good practices maybe from a more technical point of view, because my reasoning is from a more business/organization point of view as I come from a DDD background and the others don't..
As you can see, from a DDD-ish point of view, multiple producers with the need of publishing in the same topic would trigger a design-smell. I'm not saying it cannot be done, I'm trying to find out whether it should be avoided ALSO from a technical point of view.
Anyone with some hands-on experience on this?
PS: There is a similar question about Kafka but I don't think it's exactly the same as Kafka uses a different technical approach for the publisher-subscriber
UPDATE 1: I don't know NServiceBus, but I've worked a bit with MassTransit and when leveraging the topology creation to MassTransit (which is the only way afaik), it creates different topics not only per producer but per message type.
Just to add a few more reasons why I think we should always use one topic per producer as much as we can:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With