PubSub example in MassTransit

Question

After reading through the pub/sub project sample in MassTransit, it left me scratching my head.

In the sample, the client application publishes a request for the subscriber application to update the password of a fictitious user. This sample code works fine, and it's easy to follow the bouncing ball of this project.

HOWEVER--

In a real-world environment, the purpose of pub/sub (in my understanding) is to have a small number of publishers interacting with a large number of subscribers. In the case of a subscriber performing any sort of CRUD operation, shouldn't the communication pattern prevent more than one subscriber from handling the message? It would be less than desirable to have twenty subscribers attempt to update the same database record, for instance.

Is this just a case of a misguided sample project?

If pub/sub can be used for CRUD operations, how do you configure the framework to only allow one subscriber to perform an operation?

Am I just completely missing some basic info on the purpose of pub/sub?

Thanks for any clarification provided...

David

Answer 1

The scenario you refer to is usually referred to as 'competing consumers', and is quite typical of pub/sub.

If each consumer has it's own, unique queue name, each consumer will receive it's own copy of messages.

Alternatively, to get competing consumer behaviour, if consumers share the same queue name, there will be competition between the consumers for each message (so each message will only be received once)

Answer 2

You can have n-to-n, many-to-few, or few-to-many publishers to subscribers in any pub/sub system. It's really a matter of how many actors you want responding to a given message.

The sample project might not be the best, but we feel it shows what's going on. In real world cases though, it can be used for CRUD type behaviours; however it's more along the lines of many front ends sending "load data" type messages to middleware (cache) requesting a respond of same data. If that data gets updated on the front end somehow, it must publish some message indicating that and multiple middleware pieces need to update (cache, backend store, etc). [see CQRS]

Messaging in general is more about working with disconnected systems. Your specific world is more about the structure of consumers and publishers. I've seen implementations of MassTransit where most of the routes where static and it wasn't really pub/sub at all but just a lot of sends along a known topography of systems. Really understanding the concepts, the best book I know of is Enterprise Service Bus: Theory in Practice.

I hope this helps!

Edit: Also see our documentation, some of the concepts are touched on there.