For years, when a .NET developer said "I need the mediator pattern," the answer was almost automatically MediatR. Jimmy Bogard's library became the default so quickly that a lot of teams never really questioned it, they just added the NuGet package and moved on.
That changed in 2025. MediatR moved to a commercial license, and suddenly "just add MediatR" wasn't a free decision anymore. That's a good moment to take a step back and look at what the mediator pattern actually is, and to point out something a lot of developers overlook: if you're already using MassTransit in your project, you already have a mediator implementation available. No extra package, no extra license to think about.
Remark: Be aware that MassTransit switched to a commercial license as well starting from version 9.
What is the mediator pattern?
The mediator pattern is about decoupling the sender of a request from the thing that handles it. Instead of a controller or service directly calling into a handler class, it sends a message to a mediator, and the mediator figures out which handler should process it.
The benefit: your calling code doesn't need to know about the handler's dependencies, its constructor, or even which assembly it lives in. You send a command or a request, and the mediator dispatches it. This is especially useful in a CQRS-style setup, where you want a thin API layer that just sends commands and queries without wiring up every handler by hand.
MediatR popularized this for in-process messaging in .NET. But the pattern itself doesn't require MediatR, it's just an interface (Send, Publish) and some dispatch logic behind it. And that's exactly what MassTransit's mediator gives you.
Two ways to get there
If you're starting from scratch, adding MediatR is still the most well-known route. But if MassTransit is already part of your stack (and for a lot of message-driven .NET systems, it is), you're pulling in a second in-process messaging abstraction that does almost the same thing your existing library can already do.
MassTransit ships with an in-memory mediator implementation, built on the same consumer model you already use for your bus. No transport, no broker, everything runs in-process, but you get the same IConsumer<T> shape you're used to from regular MassTransit consumers.
Remark: this is a meaningful mental shift if you're coming from MediatR. MediatR is handler-based: you implement IRequestHandler<TRequest, TResponse>. MassTransit's mediator is consumer-based: you implement IConsumer<T>, the same interface you'd use for a real bus consumer. That consistency is actually the whole point, your in-process and out-of-process messaging code looks the same.
Setting it up
Add the mediator in your service registration:
builder.Services.AddMediator(cfg =>
{
cfg.AddConsumer<SubmitOrderConsumer>();
cfg.AddConsumer<GetOrderStatusConsumer>();
});
Define your message contract like you would for any MassTransit message:
public record SubmitOrder
{
public Guid OrderId { get; init; }
public Guid CustomerId { get; init; }
}
And a consumer to handle it:
public class SubmitOrderConsumer : IConsumer<SubmitOrder>
{
public async Task Consume(ConsumeContext<SubmitOrder> context)
{
var order = context.Message;
// handle the command
}
}
To send the command from a controller or minimal API endpoint, inject IMediator:
app.MapPost("/orders", async (SubmitOrder command, IMediator mediator) =>
{
await mediator.Send(command);
return Results.Accepted();
});
Request/response
Fire-and-forget commands are only half the story. If you need a response, MassTransit's mediator supports the request/response pattern too, using a request client created from IMediator:
public class GetOrderStatusConsumer : IConsumer<GetOrderStatus>
{
public async Task Consume(ConsumeContext<GetOrderStatus> context)
{
await context.RespondAsync(new OrderStatusResult
{
OrderId = context.Message.OrderId,
Status = "Processing"
});
}
}
var client = mediator.CreateRequestClient<GetOrderStatus>();
var response = await client.GetResponse<OrderStatusResult>(new GetOrderStatus { OrderId = orderId });
Same request/response shape you'd use with a real bus, just resolved in-process.
Remark: MassTransit dispatches asynchronously under the hood, but Send only completes once the consumer's Consume method completes. If the consumer throws, the exception propagates back to the caller, so your normal error handling around Send/GetResponse still works the way you'd expect.
Scoped vs singleton
IMediator is registered as a singleton, and by default each consumer gets its own DI scope. If you need several consumers in a pipeline to share the same scope (think: sharing a DbContext across steps), inject IScopedMediator instead. No extra configuration needed, it's available as soon as you've called AddMediator().
Do you lose anything?
Middleware like UseMessageRetry and UseInMemoryOutbox works with the mediator too, so you're not giving up MassTransit's pipeline behaviors just because you're not going over a transport. What you don't get: routing slip activities aren't supported through the mediator, but consumers, handlers, and sagas (including saga state machines) are fully supported.
If your project doesn't use MassTransit for anything else, MediatR (or a small hand-rolled mediator, plenty of examples of that around too) is still a reasonable choice. But if MassTransit is already in your dependency tree, you're one AddMediator() call away from not needing a second library for the same job.
That's it!