Commands vs Events

Architecture & Design
1

I wish I could find a complete guide to NSB Commands vs Events design and Azure Service Bus. SO my questions may be completely off base.

  1. I understand that Commands are (Many pubs to One Receiver) however, I may want to scale the amount of Receivers to handle more messages as they come upon the topic/queue without duplication.

2 NSB Events as I understand it could handle that… but they are (one event to many). What If I needed to scale out the event sending application.

Hope this makes sense.

I am kind of looking for a one to many where there could be more than “one to many instance” for scalaibility.

2

Welcome to the Particular discussion group, @Charles_Steinhardt.

I usually describe commands and events in the following way:

Commands are imperative (do something) verbs directed from one source (senders) to one destination, receivers (one-to-one).

Events are nouns, facts about the past (something happened), directed from one source (publishers) to zero or more destinations (subscribers).

I avoid having multiple logical senders of the same command as much as possible, as it isn’t evident in the long run who’s the owner of the command.

It’s crucial to differentiate between logical and physical architecture. I wrote on the topic a while ago at Let's get logical! On logical and physical architectural views. Senders, publishers, receivers, and subscribers described are logical components.

Scaling out doesn’t affect what described so far because it is a physical concern. If multiple instances exist of the same sender/publisher, one logical sender/publisher remains. The same applies to receivers/subscribers. Numerous instances of the same receiver or subscriber scaling out or load balancing performances or providing highly available services can exist.

3

Thank you what you say makes great sense. I’m gonna read your article and then try to reapply my question to see if I can solve it. Thank you.

4

@Charles_Steinhardt1,

I recently wrote a couple of articles that might help in clarifying the topic:

I’m also drafting a third one, as a follow-up, on scaling out.