Introduction

Yes, RabbitMQ, MassTransit, and MediatR can be used together, but they solve different problems and should not be treated as interchangeable. MediatR is for in-process message dispatch inside one application, while MassTransit plus RabbitMQ handles out-of-process messaging between processes and services.

The Responsibility Split

A useful mental model is:

• MediatR: internal application requests, commands, and notifications
• MassTransit: transport abstraction for external messaging
• RabbitMQ: the actual message broker underneath MassTransit

That means one request can move through both layers, but each layer should have a clear reason to exist.

A Common Pattern

Inside an ASP.NET Core service, a controller may send a command through MediatR. After the command is handled and the business action succeeds, the application publishes an integration event through MassTransit to RabbitMQ.

That keeps internal orchestration separate from external integration.

MediatR command

using MediatR;

public record CreateOrderCommand(string OrderId) : IRequest;

MediatR handler that publishes through MassTransit

1using System.Threading;
2using System.Threading.Tasks;
3using MassTransit;
4using MediatR;
5
6public record OrderCreated(string OrderId);
7
8public class CreateOrderHandler : IRequestHandler<CreateOrderCommand>
9{
10    private readonly IPublishEndpoint _publishEndpoint;
11
12    public CreateOrderHandler(IPublishEndpoint publishEndpoint)
13    {
14        _publishEndpoint = publishEndpoint;
15    }
16
17    public async Task Handle(CreateOrderCommand request, CancellationToken cancellationToken)
18    {
19        // business logic would go here
20        await _publishEndpoint.Publish(new OrderCreated(request.OrderId), cancellationToken);
21    }
22}

In this setup, MediatR handles the in-process command, and MassTransit publishes the external event.

Consuming RabbitMQ Messages and Forwarding to MediatR

The reverse direction also works well. A MassTransit consumer can receive a broker message and then dispatch an internal command through MediatR.

1using System.Threading.Tasks;
2using MassTransit;
3using MediatR;
4
5public class OrderCreatedConsumer : IConsumer<OrderCreated>
6{
7    private readonly IMediator _mediator;
8
9    public OrderCreatedConsumer(IMediator mediator)
10    {
11        _mediator = mediator;
12    }
13
14    public async Task Consume(ConsumeContext<OrderCreated> context)
15    {
16        await _mediator.Send(new CreateOrderCommand(context.Message.OrderId));
17    }
18}

This is useful when external messages should enter the same internal command pipeline as HTTP requests or other application entry points.

Basic Registration Example

1builder.Services.AddMediatR(cfg =>
2    cfg.RegisterServicesFromAssembly(typeof(Program).Assembly));
3
4builder.Services.AddMassTransit(x =>
5{
6    x.AddConsumer<OrderCreatedConsumer>();
7
8    x.UsingRabbitMq((context, cfg) =>
9    {
10        cfg.Host("localhost", "/", h =>
11        {
12            h.Username("guest");
13            h.Password("guest");
14        });
15
16        cfg.ConfigureEndpoints(context);
17    });
18});

This gives you both internal and broker-backed messaging in one application.

When This Combination Makes Sense

Using both tools is reasonable when:

• the service has rich internal command or query flows
• the service also integrates asynchronously with other services
• you want to keep domain handling separate from transport concerns

It is less useful when the application is very small and only needs one messaging style. In that case, using both libraries can add needless conceptual weight.

Do Not Duplicate the Same Message Flow Blindly

The biggest design mistake is sending every internal MediatR notification straight to RabbitMQ just because both exist. In-process notifications and integration events are not automatically the same thing.

Ask two separate questions:

1. does the current application need this message internally
2. do other services need this message externally

Only publish externally when the second answer is yes.

Common Pitfalls

One common problem is treating MediatR as a service bus. It is not; it works only inside the current process.

Another issue is putting broker-specific concerns into MediatR handlers. Keep transport policies such as retries, topology, and broker naming in the MassTransit layer.

A third pitfall is overengineering a simple application. If you do not need both in-process mediation and broker-based integration, using both can be more ceremony than value.

Summary

• RabbitMQ, MassTransit, and MediatR can absolutely be used together.
• MediatR is for in-process messaging; MassTransit with RabbitMQ is for cross-process messaging.
• A common pattern is MediatR for commands and MassTransit for integration events.
• MassTransit consumers can also forward incoming broker messages into MediatR.
• Use both only when each one serves a clear architectural purpose.