NServiceBus to configure CQRS event publishing

Question

We are currently creating a project based on CQRS. Each instance of the web project launches NEventStore, however, all of them have the same Persistence property (base database).

Now we want to publish the stored events: not only for our ReadModel (one for an instance of the web project), but also for additional users of the events (for example, outdated applications that also need to be informed in some way about events from our system, and much more).

Therefore, we have x event consumer (= event handlers) and y event publishers, but only one “real source” of events (the underlying EventStore database).

Q1: Is there a best practice for connecting these systems through Publish / Subscribe?

We thought about publishing events from EventStore through NServiceBus. All consumers must subscribe to the types of events that they need, so each consumer must also subscribe to possibly more than one publisher - Q2 : is this possible? We read that you cannot subscribe to the same event in several places, see: David Boike "Once you subscribe to Message1 at QueueName @ WebServer1, you will also not be able to subscribe to Message1 coming from QueueName @ WebServer2. "

Additional open-ended questions: Q3:. How to detect that the consumer has been closed forever (if he has not been successfully canceled from the bus). → The queue is running full ?! How to distinguish this from a situation where he lost his network connection a bit?

Q4: What happens if the connection between the subscription service and EventStore is not reliable and fails? Consumers successfully register with the subscription service, but EventStore does not know about the new subscription and does not deliver messages ...

Q5: Overall: How does NServiceBus handle queues? What happens when a consumer is unavailable for a long time (for example, a few days)?

Answer 1

Q1: It depends on how you subscribe to messages. NServiceBus was created so that there are business services (limited contexts) that cannot exchange data. However, in CQRS, you have bold events that contain a lot of data that is published so that subscribers can store information in their reading model. This reading model is used, for example, in the user interface. Either through a regular user interface, or through a composite interface (which collects information from several business services). So it depends on what you are looking for.

Q2: You can subscribe to several events. However, there is only one logical event publisher. Therefore, the "CustomerWasBilled" event cannot be obtained from ComponentA and ComponentB. However, you can subscribe to many different events, and each publisher can, of course, have many different subscribers.

[Udi] This publisher can be scaled on several servers, and NServiceBus will handle this for you - no need to subscribe to each machine.

Q3: I would think that this is pure administration. If he must remain online and receive messages, the queues will be filled. If it must be permanently disabled / disabled, and messages are not processed, then you will find out pretty quickly after the component is removed. But I highly recommend documenting which subscribers and publishers are related to each other, and what happens if you change the message or component.

[Udi] If this is an orderly shutdown, then it should include unsubscribing. If this is a crash ergo temporary, then you discover it with standard monitoring (WMI). To protect the queue from being filled, you can determine when the message should be discarded using the TimeToBeReceived attribute.

Q4: This is handled in NServiceBus. It stores subscriptions in a data warehouse, which can be SQL Server, RavenDB, and InMemory. But it also stores the subscriptions in memory and regularly checks to see if new subscriptions have been added. There should be no problem with NServiceBus.

Q5: MSMQ itself is reliable in nature. Of course, if your entire server crashes and all the messages were on the HD that were fried, this is the problem. If a component is unavailable for a longer time, it depends on the SLA if this can happen. You can track the number of messages in the queue or error queue. Remember also DeadLetterQueue. But NServiceBus also lets you track how long it takes to process messages.

When a component is unavailable for a long time (for example, days) than the business must decide what to do. If it processes important messages, introduces clustering, etc.

Hope this helps