Distributor and Publish-Subscribe

Events can be received by multiple logical endpoints, however even in case of scale out each event will be received only by one physical instance of any logical subscriber.

The subscribe messages are sent by the workers but contain the distributor address in the NServiceBus.ReplyToAddress header. This causes all published events to be routed to the distributor instead of directly to the workers.

Subscribe workflow

Compared to regular subscribe workflow the distributor variant contains an extra step -- forwarding the subscribe message from the distributor to the worker.

1. Subscribers request to a publisher the intent to subscribe to certain message types.
2. Distributor forwards the subscribe message to one of the workers
3. Worker stores the subscriber address and the message type in the persistence.

Publish workflow

Compared to regular publish workflow the distributor variant contains an extra step -- forwarding the message from the distributor to the worker.

1. Some code (e.g. a saga or a handler) request a message to be published.
2. Publisher queries the storage for a list of subscribers.
3. Publisher loops through the list and sends a copy of that message to each subscriber. In this case, the only subscriber is Subscriber@Distributor which is the address of the distributor node for the Subscriber endpoint.
4. Distributor takes the next worker from its ready queue and forwards the message to it.

Scaling out publishers

Publishers can also be scaled out using the distributor and it does not affect the workflow. Each worker node independently fetches the list of subscribers for each publish operation requested.