views:

30

answers:

1

Hi. I am trying to de-couple two applications using EDA and NServiceBus. Currently, I have a Sales MT and an Inventory MT. Whenever a sale is requested through the Sales MT, before it is approved the Sales MT will call the Inventory MT to make sure there is available stock. I want to change the way this works, so that the Sales MT just automatically approves it, and publishes an async "SaleCreated" event, which the Inventory MT and the Billing MT will then subscribe to. The Inventory MT can then flag the Sale in an offline process if there are any out-of-stock items.

My problem is that I have 10 instances of my Sales MT, 5 instances of my Inventory MT, and 3 instances of my Billing MT. All 3 applications have their own Virtual IP on top of a LoadBalancer that sits in front of the 10/5/3 servers. So basically I have 1 virtual publication (SaleCreated events) and 2 virtual subscriptions (Inventory and Billing subscribers). Ideally, a Sale that gets processed by the Sales MT, should create a SaleCreated event message to be sent to 1 and only 1 Inventory MT, and 1 and only one Billing MT. I am really confused how this will work, since I haven't seen examples of this scenario on the NServiceBus site. Also, I don't want to have all messages sent to a single distributor for each subscription, as that will cause one machine to be a bottleneck.

Is there any way to do this?

A: 

On the publishing side, you'd use the DB subscription storage option (found in the production profile) so that all publishing instances see the same list of subscribers. On the subscribing side, you'd use a distributor to distribute the load of events coming in so that each message is dispatch to only a single instance. Note that you'd use one distributor for each subscriber, so no real bottleneck, and the distributor doesn't do any actual work so it's not much of a concern.

Udi Dahan
Thanks, Udi. That helps. I have some follow ups:1. What do you mean by "found in the production profile"2. How does a publishing instance get notified of new subscribers in the subscription DB, it seems like checking everytime would be bad.3. It seems like there could still be a better way to distribute for subscribers. With this you have every message generated by the publisher being routed through a single box (even if you have 100 publishing boxes).
skb
To learn more about profiles (and the production profile in particular), go to http://www.nservicebus.com/Profiles.aspxWhen working with the DB, publisher instances don't need to know about new subscribers - they access the DB on every publish.If you don't want all distributors on the same box, fine - put them on different boxes. You usually partition based on message type so you could easily have a separate distribution route per message type.
Udi Dahan
So every single publish requires a roundtrip to the Subscription DB?
skb
When using the production profile / the DbSubscriptionStorage, yes. It is pluggable though, so you can provide your own implementation of ISubscriptionStorage say, over a distributed cache, for better performance in a scaled out environment.
Udi Dahan