CQRS without the cargo cult: when MediatR helps and when it hurts

Somewhere along the way, CQRS with MediatR stopped being a design decision and became the default scaffolding for .NET backends. New project, Clean Architecture template, MediatR installed before the first entity exists. I've used this stack in two real systems — my blog platform, which runs in production, and my graduation project — and I deliberately left it out of a third. The difference between those choices is the part the tutorials skip.

Strip away the pattern diagrams and MediatR is an in-process mediator: you send a request object, exactly one handler answers it, and neither side references the other directly. That decoupling is nice, but it isn't the real win. The real win is the pipeline. Cross-cutting concerns — validation, logging, transaction boundaries — wrap every request in behaviors, written once, applied everywhere.

In my blog's backend, every command and query passes through a validation behavior before it touches a handler:

public sealed class ValidationBehavior<TRequest, TResponse>
    : IPipelineBehavior<TRequest, TResponse>
    where TRequest : notnull
{
    private readonly IEnumerable<IValidator<TRequest>> _validators;

    public ValidationBehavior(IEnumerable<IValidator<TRequest>> validators)
        => _validators = validators;

    public async Task<TResponse> Handle(
        TRequest request,
        RequestHandlerDelegate<TResponse> next,
        CancellationToken cancellationToken)
    {
        if (!_validators.Any())
            return await next();

        var context = new ValidationContext<TRequest>(request);
        var results = await Task.WhenAll(
            _validators.Select(v => v.ValidateAsync(context, cancellationToken)));

        var failures = results
            .SelectMany(r => r.Errors)
            .Where(f => f is not null)
            .ToList();

        if (failures.Count != 0)
            throw new ValidationException(failures);

        return await next();
    }
}

FluentValidation validators are registered per request type, the behavior runs them all, and an invalid request never reaches business logic. My handlers assume valid input — not because I trust callers, but because the pipeline guarantees it. That's the trade MediatR offers at its best: a small amount of indirection in exchange for cross-cutting concerns living in exactly one place.

The second win is shape. One handler per use case makes the application layer read like a table of contents:

public sealed record PublishPostCommand(string Slug)
    : IRequest<Result>;

public sealed class PublishPostCommandHandler
    : IRequestHandler<PublishPostCommand, Result>
{
    private readonly IApplicationDbContext _context;

    public PublishPostCommandHandler(IApplicationDbContext context)
        => _context = context;

    public async Task<Result> Handle(
        PublishPostCommand request,
        CancellationToken cancellationToken)
    {
        var post = await _context.Posts
            .FirstOrDefaultAsync(p => p.Slug == request.Slug, cancellationToken);

        if (post is null)
            return Result.Failure("Post not found.");

        post.Status = PostStatus.Published;
        post.PublishedAt = DateTime.UtcNow;

        await _context.SaveChangesAsync(cancellationToken);
        return Result.Success();
    }
}

No god-service with forty methods. Each use case is a small, testable unit, and adding a feature means adding files, not editing a shared service until it resists change.

Validation is the behavior everyone demos — and in El-Hakim's codebase today, it is the only one registered. The transaction behavior is the other half of this design, the one I reach for when a command has to succeed or fail as a single unit: every such command runs inside a database transaction — commit if the handler completes, roll everything back if it throws.

public sealed class TransactionBehavior<TRequest, TResponse>
    : IPipelineBehavior<TRequest, TResponse>
    where TRequest : notnull
{
    private readonly IApplicationDbContext _context;

    public TransactionBehavior(IApplicationDbContext context)
        => _context = context;

    public async Task<TResponse> Handle(
        TRequest request,
        RequestHandlerDelegate<TResponse> next,
        CancellationToken cancellationToken)
    {
        // Queries don't write — let them pass straight through.
        if (request is not ICommand)
            return await next();

        await using var transaction =
            await _context.BeginTransactionAsync(cancellationToken);

        try
        {
            var response = await next();
            await transaction.CommitAsync(cancellationToken);
            return response;
        }
        catch
        {
            await transaction.RollbackAsync(cancellationToken);
            throw;
        }
    }
}

Why does this live in the pipeline instead of inside each handler? Because a transaction boundary is a property of the use case, not of any single handler. If every handler opened its own transaction, some command would eventually execute half inside one and half outside, because someone forgot. The pipeline makes the rule un-skippable: every command, always, and no handler author has to remember.

El-Hakim is my personal platform — blog, portfolio, job applications, comments, media, likes. It runs Clean Architecture on .NET 10, and the Application layer is organized as commands and queries through MediatR. The feature count is exactly the situation the pattern suits: many use cases, shared validation rules, and a codebase I maintain alone, where consistency matters more than cleverness. When every feature enters through the same pipeline, I never have to remember which controller validates and which one forgot.

Most CQRS writing is about writes. Half my traffic is reads, and the query side is where the separation earns its keep. This is the query behind the blog's post list:

public sealed record GetPostsQuery(int Page, int PageSize)
    : IRequest<PagedResult<PostListItemDto>>;

public sealed class GetPostsQueryHandler
    : IRequestHandler<GetPostsQuery, PagedResult<PostListItemDto>>
{
    private readonly IApplicationDbContext _context;

    public GetPostsQueryHandler(IApplicationDbContext context)
        => _context = context;

    public async Task<PagedResult<PostListItemDto>> Handle(
        GetPostsQuery request,
        CancellationToken cancellationToken)
    {
        var query = _context.Posts
            .AsNoTracking()
            .Where(p => p.Status == PostStatus.Published)
            .OrderByDescending(p => p.PublishedAt);

        var total = await query.CountAsync(cancellationToken);

        var items = await query
            .Skip((request.Page - 1) * request.PageSize)
            .Take(request.PageSize)
            .Select(p => new PostListItemDto(
                p.Slug,
                p.Title,
                p.Excerpt,
                p.PublishedAt))
            .ToListAsync(cancellationToken);

        return new PagedResult<PostListItemDto>(
            items, total, request.Page, request.PageSize);
    }
}

Three things matter here. AsNoTracking, because a read that will never be written back shouldn't pay for change tracking. The projection happens inside the query, so the database returns exactly the DTO the page needs — no entity materialized just to be mapped and thrown away. And pagination happens at the source, before a single row crosses the wire. Queries don't need behaviors stacked on them, and they don't need to travel the same road commands do. That asymmetry is the actual point of splitting reads from writes.

AIO Academic Hub, my graduation project, is where I learned the limits. Under simultaneous exam submissions, the system hit database lock contention. We applied CQRS with MediatR — but I want to be precise about what fixed what. Separating the write path made the submission flow explicit, and that explicitness is what let us attach the things that actually relieved the contention: Redis session caching and persistent background queues for the heavy processing. CQRS didn't remove a single lock. It gave us a seam where the fix could go. That's a more modest claim than most CQRS write-ups make, and it's the honest one.

GeoGuard is a .NET API I built as a technical assessment: country-based IP blocking with a hard constraint — no database. All state lives in thread-safe in-memory collections, a ConcurrentDictionary for blocked countries and a ConcurrentQueue for the audit log of access attempts. The use-case surface is small: block a country, unblock it, check an IP, read the attempt log.

For that surface, MediatR would have been cargo cult. I wrote in the project's README that a dedicated Application layer was deliberately omitted — the use cases are straightforward enough that splitting them out would create unnecessary abstraction and plumbing, so the domain encompasses the orchestration. A plain service does the work:

public sealed class CountryBlockService
{
    private readonly IBlockedCountryRepository _countries;
    private readonly IGeolocationService _geolocation;
    private readonly IBlockedAttemptRepository _attempts;

    public CountryBlockService(
        IBlockedCountryRepository countries,
        IGeolocationService geolocation,
        IBlockedAttemptRepository attempts)
    {
        _countries = countries;
        _geolocation = geolocation;
        _attempts = attempts;
    }

    public async Task<AccessDecision> CheckAccessAsync(
        IPAddress ip, CancellationToken ct = default)
    {
        var country = await _geolocation.LookupAsync(ip, ct);

        if (country is not null && _countries.IsBlocked(country))
        {
            _attempts.Log(new BlockedAttemptLog(ip, country, DateTime.UtcNow));
            return AccessDecision.Blocked(country);
        }

        return AccessDecision.Allowed();
    }
}

And this is the store underneath it — the entire persistence layer for country blocking:

public sealed class InMemoryBlockedCountryStore
    : IBlockedCountryRepository
{
    private readonly ConcurrentDictionary<CountryCode, DateTime> _blocked = new();

    public void Block(CountryCode country)
        => _blocked[country] = DateTime.UtcNow;

    public void Unblock(CountryCode country)
        => _blocked.TryRemove(country, out _);

    public bool IsBlocked(CountryCode country)
        => _blocked.ContainsKey(country);

    public IReadOnlyCollection<CountryCode> GetBlocked()
        => _blocked.Keys.ToList();
}

That's it. No DbContext, no migrations, no repository-over-EF ceremony — a thread-safe dictionary behind an interface, because the assessment's no-database constraint made in-memory the honest design. If that constraint ever changes, the interface is the seam; the service above it doesn't move.

No mediator, no handlers, no validators — and also no AutoMapper or FluentValidation, for the same reason. The code is shorter, the call stack is honest, and a reviewer can read the whole flow in one sitting. Leaving a pattern out was a design decision, documented like one.

MediatR's costs are real, they're just quiet. Debugging means stepping through the mediator instead of jumping straight to the implementation; "go to definition" lands on an interface, not the handler. Every use case costs you several files — request, handler, validator — which is a fair price at fifty use cases and pure ceremony at five. And the pattern name itself causes confusion: CQRS is an architectural idea about separating reads from writes; MediatR is a library. You can split your read and write models without a mediator, and you can use a mediator with a single shared model — most "CQRS" codebases, mine included, do the latter and should say so.

The failure mode I see most is the CRUD app wearing enterprise clothing: four entities, basic create-read-update-delete, and a full CQRS pipeline adding latency to development, not removing complexity from the system. The pattern was invented for systems where the write side and the read side genuinely pull in different directions. If yours don't, the pipeline is a toll booth on a road with no traffic.

• Reach for MediatR when cross-cutting behaviors — validation, auditing, transactions — need one home across many use cases.

• Reach for it when the feature count keeps growing and a shared service class is turning into a junk drawer.

• Skip it when the use cases are few, straightforward, and unlikely to multiply — a plain service is easier to read, debug, and delete.

• Skip it when the constraint is smallness itself: assessments, prototypes, single-purpose services.

Laid side by side, the three systems make the argument better than any diagram:

• El-Hakim → MediatR pipeline. Many features, shared validation rules, one maintainer. Consistency wins, so the pipeline pays for itself.

• AIO Academic Hub → CQRS as the seam. It fixed no locks by itself; it made Redis caching and background queues attachable without restructuring the system.

• GeoGuard → plain services, no mediator. Four use cases and a hard no-database constraint. A pipeline there would have been weight without payoff.

Patterns are tools with price tags. CQRS with MediatR has paid for itself in two of my systems and would have taxed the third for nothing. The skill isn't knowing the pattern — it's knowing which of your systems is which.