| title | summary | reviewed | component | isLearningPath | redirects | related | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Message routing |
How NServiceBus routes messages between endpoints. |
2024-12-31 |
Core |
true |
|
|
The routing subsystem is responsible for finding destinations for messages. In most cases, the code which sends messages should not specify the destination of the message being sent:
snippet: BasicSend
The routing subsystem will provide the destination address based on the message type.
NServiceBus routing consists of two layers: logical and physical. Logical routing defines which logical endpoint should receive a given outgoing message. Physical routing defines to which physical instance of the selected endpoint the message should be delivered. While logical routing is a developer's concern, physical routing is controlled by operations.
Broker transports handle the physical routing automatically. Other transport might require specific configuration. See also MSMQ Routing.
As described in messages, events, and commands, NServiceBus distinguishes between these kinds of messages. Command messages are always routed to a single logical endpoint.
partial: commands
Per-namespace routes override assembly-level routes, while per-type routes override both namespace and assembly routes.
In specific cases, like sending to the same endpoint or a specific queue (e.g., for integration purposes), the routing configuration can be overridden when sending a message. Refer to documentation on sending messages for further details.
When events are published, they can be received by multiple logical endpoints. However, even in cases where those logical endpoints are scaled out, each event will be received by only one physical instance of a specific logical subscriber. It is important to note that before the event is published and delivered, the subscriber has to express its interest in that event by having a message handler for it.
Multicast transports support the Publish-Subscribe pattern natively. In this case, the subscriber uses the transport APIs to create a route for a given subscribed message type.
Other transports do not support Publish-Subscribe natively. These transports emulate the publish behavior by sending a message to each subscriber directly. To do this, the publisher endpoint has to know its subscribers, and subscribers have to notify the publisher about their interest in a given event type. The notification message (known as the subscribe message) must be routed to the publisher.
partial: events
Reply messages are always routed based on the ReplyTo header of the initial message, regardless of the endpoint's routing configuration. Only the sender of the initial message can influence the routing of a reply. Refer to documentation on sending messages for further details.
When using a message broker, multiple instances of a scaled-out endpoint are consuming from the same address via the competing consumer model.
To address specific instances of a scaled-out endpoint, instances can be configured to be individually addressable by providing a unique discriminator to each instance:
The following queues will be created for endpoint Sales configured with discriminator B:
SalesSales-B
var endpointConfiguration = new EndpointConfiguration("Sales");
endpointConfiguration.MakeInstanceUniquelyAddressable("B");Uniquely addressable instances are used for callbacks but can be used for other purposes like data partitioning with processing affinity or a form or processing prioritization.
var options = new SendOptions();
options.RouteToSpecificInstance("B");
endpointInstance.Send(new MyMessage(), options);Recommendations:
- Avoid hard-coding the discriminator when sending messages.
- Avoid using
MakeInstanceUniquelyAddressablefor priority queues. - Consider using routing extensibility for routing to specific instances.