AI agents: use the documentation index at llms.txt to locate machine-readable pages. This section is indexed by https://docs.particular.net/transports/llms.txt. The markdown version of this page is served as plain text. An MCP server at /mcp serves the same content via the search_docs and read_doc tools; it is read-only and needs no credentials. Markdown versions of documentation pages are available by appending .md to the page URL. Directory URLs use index.md. They are served as text/plain because some retrieval backends reject text/markdown.

RabbitMQ Transport

Target Version:
NServiceBus 7.x
Standard support for version 7.x of NServiceBus has expired. For more information see our Support Policy.

The RabbitMQ Transport provides support for sending messages over RabbitMQ using the RabbitMQ .NET Client.

Broker compatibility

The transport is compatible with RabbitMQ broker version 3.10.0 or higher.

The stream_queue and quorum_queue feature flags must be enabled because the delay infrastructure requires at-least-once dead lettering.

The broker requirements can be verified with the delays verify command provided by the command line tool.

Hosted broker options

The transport has been confirmed to work with the following hosting providers:

Transport at a glance

Feature
TransactionsReceiveOnly
Pub/SubNative
TimeoutsNative
Large message bodiesBroker can handle arbitrary message size within available resources, very large messages via data bus
Scale-outCompeting consumer
Scripted DeploymentSupported using NServiceBus.Transport.RabbitMQ.CommandLine
InstallersMandatory
Native integrationSupported
Case SensitiveYes
Aspire integrationYes

Configuring the endpoint

To use RabbitMQ as the underlying transport:

endpointConfiguration.UseTransport<RabbitMQTransport>();

The RabbitMQ transport requires a connection string to connect to the broker. A clustered configuration is recommended. See connection settings for options on how to provide the connection string.

Routing topology

Routing topologies are used to control how queues, exchanges, and bindings are created on the RabbitMQ broker. Selecting a routing topology is mandatory. For new deployments, the ConventionalRoutingTopology (previously the default) should be selected:

var transport = endpointConfiguration.UseTransport<RabbitMQTransport>();
transport.UseConventionalRoutingTopology(QueueType.Quorum);

See the routing topology documentation for further details.

Advantages and disadvantages

Advantages

  • Provides native reliability and high-availability features.
  • Offers a native publish-subscribe mechanism; therefore it doesn't require NServiceBus persistence for storing event subscriptions.
  • Supports a wide range of clients which allows for integrating the system with applications written in other languages using native RabbitMQ features.
  • Supports the competing consumers pattern out of the box. Messages are received by instances in a round-robin fashion without additional configuration.

Disadvantages

  • Doesn't handle network partitions well; partitioning across a WAN requires dedicated features.
  • Requires careful consideration for duplicate messages, e.g. using the outbox feature or making all endpoints idempotent.
  • Many organizations don't have the same level of expertise with RabbitMQ as with other technologies, such as SQL Server, so it may require additional training.
  • May require additional costs of commercial RabbitMQ license and support.

Controlling delivery mode

In AMQP, the delivery_mode controls how the broker treats the message from a durability standpoint. NServiceBus will default to persistent in order to prevent message loss. To optimize for higher throughput this can be changed to non-persistent.

See the the non-durable messaging documentation for more details.

List of Samples

Related Articles