Transports

Transports are the underlying infrastructure components responsible for physically moving messages between services. They define how messages are delivered, stored, routed, redelivered, and acknowledged, whether that means queues and exchanges in RabbitMQ, topics, queues, and subscriptions in Azure Service Bus, or other broker-specific mechanisms. MassTransit sits above the transport, providing a consistent programming model so that application code can focus on messages, producers, and consumers — not broker-specific APIs or topology details.

Each transport comes with its own capabilities and trade-offs around durability, ordering, scalability, and operational complexity. MassTransit exposes those capabilities through a unified abstraction while still allowing you to opt into transport-specific features when they matter. Later in this section, you’ll also see how Riders fit into this model to integrate additional transports (such as Kafka or Azure Event Hubs) alongside a bus, enabling hybrid messaging and streaming architectures.

Supported message brokers

MassTransit provides first-class support for a variety of transports, most of which are message brokers. Brokers such as RabbitMQ and Azure Service Bus are built around queues and topics, while Amazon SQS achieves similar behavior when combined with SNS. These systems share a common delivery model: messages are dispatched to consumers, locked while being processed, and removed from the queue once successfully handled. If a consumer disconnects or fails, the message is automatically redelivered to another consumer.

This dispatch-oriented model is the foundation of most message-driven systems and maps naturally to MassTransit’s core abstractions: consumers, endpoints, retries, and fault handling.

RabbitMQ

RabbitMQ is the most popular MassTransit transport and is often the default choice for production systems. It provides durable queues, exchanges, and routing keys, enabling flexible message topologies and high-throughput dispatch. RabbitMQ supports competing consumers, message acknowledgements, retries, dead-letter queues, and delayed delivery, all of which map naturally to MassTransit’s core abstractions. It is a strong fit for systems that require predictable behavior, fine-grained routing control, and operational visibility.

For configuration details and examples, refer to the RabbitMQ documentation.

Azure Service Bus

Azure Service Bus is a fully managed cloud broker designed for enterprise workloads on Azure. It supports queues, topics, and subscriptions with built-in features such as message locking, duplicate detection, scheduled delivery, and dead-lettering. MassTransit integrates deeply with Azure Service Bus, exposing these capabilities through a consistent programming model while handling topology and subscription management automatically. It is well suited for cloud-native systems that prioritize reliability, security, and minimal operational overhead.

For configuration details and examples, refer to the Azure Service Bus documentation.

Amazon SQS / SNS

Amazon SQS, paired with SNS, provides a highly scalable, fully managed messaging solution on AWS. SQS offers durable queues with at-least-once delivery, while SNS enables fan-out, pub/sub-style message distribution. When used together, they provide dispatch semantics similar to traditional brokers, though with some constraints around ordering and routing. MassTransit abstracts these details, allowing consumers and publishers to be written consistently while leveraging AWS-managed infrastructure.

For configuration details and examples, refer to the Amazon SQS/SNS documentation.

SQL Server / PostreSQL

The SQL transport enables durable messaging backed by a relational database such as SQL Server or PostgreSQL. Messages are stored in tables and processed using database transactions, making this transport ideal for environments where introducing an external broker is not possible or desirable. While not designed for extreme throughput, SQL transport provides strong consistency, simple deployment, and excellent suitability for smaller systems, regulated environments, or scenarios where messaging must live alongside existing transactional data.

For configuration details and examples, refer to the SQL transport documentation.

ActiveMQ

ActiveMQ support exists for environments that rely on traditional JMS-style brokers or established enterprise messaging infrastructure. It provides queues and topics with dispatch-based delivery semantics similar to other classic message brokers. MassTransit integrates with ActiveMQ to offer the same consumer, saga, and workflow patterns available on other transports, making it possible to modernize application code without replacing the underlying broker immediately.

For configuration details and examples, refer to the ActiveMQ documentation.

In-Memory Transport

The In-Memory transport is a lightweight, non-durable transport intended primarily for development and testing. Messages are delivered within the same process without persistence, external infrastructure, or network communication. It does not provide durability or cross-process delivery, and it is invaluable for unit tests.

For configuration details and examples, refer to the In-Memory documentation.

Supported stream services

In contrast, event streaming platforms such as Kafka and Azure Event Hubs follow a very different model. Messages are appended to a log rather than dispatched to a single consumer. They are not removed once processed, ordering is fundamental, and consumers are responsible for tracking their own position in the stream. As event streaming has become mainstream, it became clear that many traditional messaging concepts and idioms do not apply directly. Supporting these platforms required new patterns and a clear distinction between dispatch brokers and streaming systems.

Riders provide a clean, explicit way to integrate event streaming platforms alongside a traditional bus. A rider is configured together with the bus and boards the bus when it starts, sharing the same container, lifecycle, and observability context.

Riders can define receive endpoints, configure consumers and saga state machines, and interact with the bus by sending or publishing messages. When supported by the underlying platform, riders can also produce messages directly to the stream.

Kafka

Apache Kafka is a distributed streaming platform for building real-time data pipelines and streaming applications. It is written in Scala and Java and is built on the Apache Kafka project, which provides a high-performance, fault-tolerant, and scalable infrastructure for handling streams of records in real-time.

Kafka is designed to handle high volume, high throughput, and low-latency data streaming. It can handle millions of events per second and can handle terabytes of data without data loss. It stores streams of records in a fault-tolerant way and allows real-time data processing.

Kafka uses a publish-subscribe model where producers write data to topics and consumers read data from topics. Topics are split into partitions and each partition is replicated across multiple brokers for fault tolerance.

Kafka also supports various features such as, built-in support for data compression, data partitioning and replication, and built-in, centralized exception handling system that allows for easier debugging and error reporting.

Kafka is often used in big data and real-time data pipeline architectures, it’s used for stream processing, log aggregation, real-time analytics, and event sourcing. It can be integrated with many programming languages and frameworks, including Java, .NET, C++, Ruby, and Python.

Kafka topics can be consumed using MassTransit consumers and saga state machines. Messages can also be produced to Kafka topics using the Kafka rider’s producer interfaces.

For configuration details and examples, refer to the Kafka documentation.

Azure Event Hubs

Azure Event Hubs is a fully managed event streaming platform designed for ingesting and processing large volumes of event data in real time. It provides a scalable, fault-tolerant infrastructure for handling streams of events, similar in purpose to Apache Kafka, and is commonly used for telemetry, event ingestion, and real-time analytics.

Event Hubs is built to handle high throughput and low latency, capable of processing millions of events per second with predictable performance. Events are written to a durable, append-only stream and retained for a configurable period of time, allowing multiple consumers to process the same stream independently. Unlike traditional message brokers, events are not removed after consumption; consumers track their own position within the stream.

Event Hubs uses a publish-subscribe model where producers send events to an event hub and consumers read from partitions within that hub. Each partition represents an ordered sequence of events, and partitions are distributed across the service for scalability and fault tolerance. Consumer groups enable multiple independent applications to consume the same event stream without interfering with one another.

The platform includes built-in support for partitioning, batching, checkpointing, and integration with Azure services such as Azure Functions, Stream Analytics, and Data Explorer. Security is handled through shared access policies and Azure Active Directory, making it suitable for enterprise and cloud-native environments.

Azure Event Hubs is commonly used for event streaming, telemetry pipelines, and real-time analytics scenarios. MassTransit integrates with Event Hubs through the Event Hub rider, allowing events to be consumed using MassTransit consumers and saga state machines, and produced to event hubs using rider-specific producer interfaces.

Azure Event Hubs can be consumed using MassTransit consumers and saga state machines. Messages can also be produced directly to event hubs using the Event Hub producer interfaces.

For configuration details and examples, refer to the Azure Event Hubs documentation.