Alternativas ao MassTransit: Rebus e NServiceBus comparados

O Rebus é a alternativa mais forte ao MassTransit para a maioria das equipes .NET: tem licença MIT, é gratuito para empresas de qualquer porte e é pequeno o bastante para ser lido em uma tarde. O NServiceBus é a alternativa a escolher quando estamos comprando suporte e ferramentas, e não economizando dinheiro.

Se as pessoas chegam a procurar uma alternativa, o motivo é comercial: o MassTransit passou para uma licença paga, com código-fonte disponível, a partir da v9, então os caminhos gratuitos são estes: um desconto de 100% (para o qual podem se qualificar organizações com receita inferior a US$ 1 milhão), continuar na v8 ou deixar o MassTransit. Qual das três bibliotecas se encaixa melhor depende dos transportes, do suporte a sagas e do orçamento. A seguir, comparamos as três em cada um desses pontos.

Artigos relacionados: Publicar notificações do MediatR em paralelo · Como usar o padrão REPR no .NET

Apresentação dos concorrentes

Para mensageria no .NET, Rebus, NServiceBus e MassTransit são as principais opções, então vamos examinar o que cada uma oferece.

Primeiro, vamos definir uma mensagem simples:

public class Message
{
    public string MessageId { get; set; } = string.Empty;
    public string Content { get; set; } = string.Empty;
}

Mais adiante no artigo, vamos tratar mensagens desse tipo. Criamos um projeto ASP.NET Core para cada biblioteca, e cada projeto recebe uma cópia desta classe e dos tipos compartilhados que vamos definir depois.

Rebus

O Rebus é um barramento de serviços leve e de código aberto, focado em simplicidade e facilidade de uso. Ele exige uma configuração mínima, o que permite aos desenvolvedores implementar sistemas de mensageria rapidamente.

O README do Rebus resume isso em uma linha: “O Rebus é uma implementação enxuta de barramento de serviços para .NET”, construída com o mínimo possível de dependências.

A maior vantagem do Rebus é sua flexibilidade e extensibilidade, o que nos permite adaptá-lo aos requisitos específicos do nosso projeto.

Agora, vamos configurar o Rebus:

using Rebus.Config;
using Rebus.Routing.TypeBased;
using Rebus.Transport.InMem;

builder.Services.AddRebus(configure => configure
    .Transport(t => t.UseInMemoryTransport(new InMemNetwork(true), "MyQueue"))
    .Routing(r => r.TypeBased().MapAssemblyOf<Message>("MyQueue")));
builder.Services.AutoRegisterHandlersFromAssemblyOf<Program>();

Aqui, configuramos o Rebus para usar uma camada de transporte em memória e rotear todos os tipos de mensagem do assembly de Message para a fila designada. 

Por fim, o método AutoRegisterHandlersFromAssemblyOf<Program>() registra todos os handlers do nosso assembly. Tanto esse método quanto AddRebus() vêm do pacote Rebus.ServiceProvider.

Em resumo, o Rebus é ideal para aplicações pequenas e médias em que a simplicidade e a facilidade de uso são prioridades. Nosso guia sobre como começar a usar o Rebus no .NET mostra um primeiro projeto do início ao fim.

NServiceBus

Em seguida, temos o NServiceBus, um barramento de serviços rico em recursos, projetado para aplicações corporativas. Ele oferece funcionalidades avançadas que o tornam adequado para sistemas corporativos de grande escala.

O que diferencia o NServiceBus é seu conjunto de ferramentas de monitoramento e depuração, como o ServicePulse e o ServiceInsight, uma aplicação desktop que a Particular colocou em fase de descontinuação e que será declarada obsoleta em 10 de fevereiro de 2027. Essas ferramentas oferecem visibilidade em tempo real do nosso sistema de mensageria, o que facilita a manutenção e a solução de problemas.

No entanto, preparar o NServiceBus exige mais configuração que o Rebus; em compensação, isso traz mais controle e um conjunto rico de recursos:

builder.Host.UseNServiceBus(context =>
{
    var endpointConfiguration = new EndpointConfiguration("HandlerEndpoint");

    var transport = endpointConfiguration.UseTransport<LearningTransport>();
    var serialization = endpointConfiguration.UseSerialization<SystemJsonSerializer>();

    var routing = transport.Routing();
    routing.RouteToEndpoint(typeof(Message), "HandlerEndpoint");

    return endpointConfiguration;
});

Neste exemplo, configuramos o NServiceBus para usar LearningTransport como camada de transporte e rotear as instâncias da classe Message para o endpoint designado. O próprio método UseNServiceBus() vem do pacote NServiceBus.Extensions.Hosting. O NServiceBus 10.2 marca esse método como obsoleto; o substituto é o método nativo AddNServiceBusEndpoint().

Graças ao excelente suporte comercial da Particular Software, o NServiceBus é uma ótima escolha para aplicações corporativas de grande escala.

MassTransit

Por fim, o MassTransit é um barramento de serviços focado em facilidade de uso e flexibilidade. A versão 8 e as anteriores usam a licença Apache-2.0, e a versão 9 é comercial, com código-fonte disponível. A documentação de licenciamento do MassTransit é direta sobre o que isso significa: “O MassTransit v9 (e as versões seguintes) exige uma licença de uso, que dá a você um arquivo de chave de licença.”

O MassTransit encontra um equilíbrio entre a simplicidade do Rebus e os recursos avançados do NServiceBus, o que o torna uma opção versátil para uma ampla variedade de aplicações.

Um dos pontos fortes do MassTransit são suas APIs de configuração fluente, que simplificam o processo de configuração. Ele também oferece suporte a padrões avançados de mensageria, incluindo sagas e máquinas de estado:

using MassTransit;

builder.Services.AddMassTransit(x =>
{
    x.AddConsumer<MassTransitMessageHandler>(); 
    x.UsingInMemory((context, cfg) =>
    {
        cfg.ConfigureEndpoints(context);
    });
});

Da mesma forma, configuramos o MassTransit para usar uma camada de transporte em memória e definimos MassTransitMessageHandler como consumidor de mensagens.

O MassTransit equilibra desempenho e complexidade, o que o torna útil em aplicações médias e grandes. Para vê-lo conectado a um broker real, leia nosso guia sobre MassTransit com RabbitMQ no ASP.NET Core.

Transportes e protocolos compatíveis

Em seguida, vamos ver como eles diferem quanto aos transportes compatíveis.

A escolha do transporte pode afetar significativamente nosso sistema de mensageria, dependendo da infraestrutura que já temos e dos requisitos de desempenho.

Vejamos uma comparação rápida dos transportes compatíveis:

Como podemos ver, além das opções comuns, o NServiceBus e o Rebus também oferecem suporte ao MSMQ, mas apenas no .NET Framework, o que pode beneficiar sistemas legados ou ambientes que exigem protocolos de mensageria específicos. Quando o alvo é o RabbitMQ, nosso guia sobre RabbitMQ no ASP.NET Core explica como configurar o próprio broker.

Implementação de sagas

Gerenciar processos complexos e de longa duração muitas vezes exige coordenar várias mensagens e manter o estado entre diferentes etapas.

É aqui que entram as sagas. As sagas são um padrão que ajuda a gerenciar esses fluxos de trabalho, garantindo a consistência dos dados e orquestrando a sequência de operações.

Primeiro, temos a saga baseada em coreografia, em que um barramento de mensagens transfere as mensagens entre produtores e consumidores:

Como alternativa, podemos substituir o barramento de mensagens por um serviço especializado que orquestra a saga e, assim, chegar a uma saga baseada em orquestração:

Vale notar que as três bibliotecas oferecem suporte às duas implementações do padrão saga.

Se quiser saber mais sobre como implementar o padrão saga, leia nossos artigos sobre as implementações com NServiceBus e com Rebus.

Tratamento de erros e novas tentativas

O tratamento de erros é essencial em qualquer sistema de mensageria, pois garante que cada mensagem seja processada mesmo quando surgem problemas inesperados. Cada biblioteca oferece mecanismos diferentes para tratar erros e implementar políticas de novas tentativas.

Tratamento de erros e novas tentativas no Rebus

O Rebus oferece uma abordagem direta para o tratamento de erros e as novas tentativas de processar mensagens. Por padrão, o Rebus tenta processar uma mensagem várias vezes antes de movê-la para uma fila de erros. Esse comportamento garante que problemas transitórios, como falhas temporárias de rede ou disputa por recursos, não resultem em mensagens perdidas.

Vamos personalizar o comportamento das novas tentativas no Rebus com o método RetryStrategy(), encadeado depois de Routing() na nossa chamada a AddRebus():

using Rebus.Retry.Simple;

.Options(o => o.RetryStrategy(
    maxDeliveryAttempts: 5,
    secondLevelRetriesEnabled: true,
    errorQueueName: "ErrorQueue"
))

Neste exemplo, a opção maxDeliveryAttempts controla quantas vezes o Rebus tentará entregar a mensagem imediatamente. A opção secondLevelRetriesEnabled faz o Rebus despachar a mensagem de novo, encapsulada em um IFailed<Message>, depois que a primeira série de tentativas falhar. Por fim, errorQueueName define a fila de erros para onde a mensagem vai se todas as tentativas falharem.

Explicando melhor: as primeiras tentativas são imediatas, ou seja, o Rebus tenta processar a mensagem de novo rapidamente, sem atraso. Se todas essas tentativas falharem, as novas tentativas de segundo nível entregam a mensagem a um handler de IFailed<Message>, que pode adiá-la para uma nova tentativa mais tarde, em vez de deixá-la ir imediatamente para a fila de erros.

Esses atrasos dão tempo para que condições temporárias, como instabilidade de rede ou indisponibilidade de um serviço externo, se resolvam.

Tratamento de erros e novas tentativas no NServiceBus

O NServiceBus também oferece mecanismos nativos de novas tentativas, tanto imediatas quanto com atraso.

Vamos configurar as novas tentativas imediatas e com atraso usando as configurações de Recoverability:

var recoverability = endpointConfiguration.Recoverability();

recoverability.Immediate(immediate => 
    immediate.NumberOfRetries(3)
);

recoverability.Delayed(delayed =>
{
    delayed.NumberOfRetries(2); 
    delayed.TimeIncrease(TimeSpan.FromSeconds(5));
});

endpointConfiguration.SendFailedMessagesTo("ErrorQueue");

Neste exemplo, se o processamento da mensagem falhar, o NServiceBus fará três novas tentativas imediatas e, depois, duas novas tentativas com atraso, cada uma seguida de mais uma rodada de três tentativas imediatas. Se todas as novas tentativas falharem, o NServiceBus move a mensagem para a fila de erros.

Além disso, o NServiceBus nos permite implementar políticas de novas tentativas personalizadas por meio de uma política de recuperabilidade personalizada:

recoverability.CustomPolicy((config, context) =>
{
    if (context.Exception is TimeoutException)
    {
        return RecoverabilityAction.ImmediateRetry();
    }
    
    return RecoverabilityAction.MoveToError("ErrorQueue");
});

Como podemos ver, o NServiceBus fará uma nova tentativa imediata apenas no caso de uma exceção TimeoutException, sem limite para o número de novas tentativas. Caso contrário, ele redireciona a mensagem para uma fila de erros.

Tratamento de erros e novas tentativas no MassTransit

O MassTransit também oferece recursos flexíveis de tratamento de erros e de novas tentativas por meio do seu middleware nativo. Ele permite configurar novas tentativas com várias estratégias, como tentativas imediatas, intervalos e backoff exponencial.

Vamos definir a política de novas tentativas para todos os endpoints com o MassTransit:

cfg.UseMessageRetry(r => r.Interval(3, TimeSpan.FromSeconds(2)));

Neste exemplo, Interval() especifica que o MassTransit deve fazer três novas tentativas de processar a mensagem, com um intervalo de 2 segundos entre elas. Se todas as novas tentativas falharem, o MassTransit move a mensagem para uma fila de erros.

O MassTransit cria filas de erros automaticamente, acrescentando _error ao final do nome de cada endpoint.

Monitoramento e instrumentação

Monitorar a integridade e o desempenho das nossas aplicações é crucial para identificar possíveis problemas logo no início. Cada biblioteca oferece ferramentas e integrações diferentes para nos ajudar a monitorar nossos sistemas.

O Rebus e o MassTransit se integram com frameworks de logging como o Serilog, o que nos permite capturar logs.

Em comparação com o Rebus e o MassTransit, o NServiceBus vai além no monitoramento, com ferramentas dedicadas como o ServicePulse e, até fevereiro de 2027, o ServiceInsight.

O ServicePulse oferece monitoramento em tempo real dos nossos endpoints, destacando as mensagens com falha e fornecendo informações sobre o desempenho do sistema.

O ServiceInsight permite visualizar os fluxos de mensagens e examinar a fundo o pipeline de processamento de mensagens, o que é inestimável para solucionar problemas complexos. O ServicePulse também mostra os fluxos de mensagens, e a Particular recomenda migrar para ele antes que o ServiceInsight seja declarado obsoleto.

Além disso, todas as bibliotecas oferecem suporte ao OpenTelemetry, que podemos usar para coletar métricas e enviá-las às nossas ferramentas de análise preferidas, como Grafana ou Prometheus.

Recursos de segurança

A segurança é a preocupação mais importante na transmissão de mensagens entre serviços, especialmente em sistemas distribuídos, em que os dados podem passar por redes não seguras. Nos trechos de código a seguir, encryptionKey é uma string que contém uma chave de 32 bytes codificada em Base64, e encryptionKeyId é uma string que identifica essa chave para o NServiceBus. Declaramos as duas no Program.cs, acima da configuração do barramento.

Criptografia no Rebus

O Rebus oferece suporte à proteção de mensagens em trânsito e em repouso. Ele aproveita os recursos de segurança dos mecanismos de transporte subjacentes, como a criptografia SSL/TLS em protocolos como HTTPS ou AMQP.

Vejamos como habilitar a criptografia automática do corpo das mensagens no Rebus, com mais uma chamada no mesmo encadeamento:

.Options(o => o.EnableEncryption(encryptionKey))

O método EnableEncryption(), do namespace Rebus.Encryption, aceita uma chave de criptografia codificada em Base64. Por padrão, o Rebus usa essa chave para criptografar o corpo das mensagens com o algoritmo AES.

Se não fornecermos uma chave válida, o Rebus lança uma exceção cuja mensagem traz uma chave nova, gerada com a funcionalidade nativa do .NET, que podemos armazenar na configuração.

Devemos lembrar que a criptografia se aplica apenas ao corpo da mensagem, enquanto os dados do cabeçalho da mensagem continuam sem criptografia.

Criptografia no NServiceBus

Da mesma forma, o NServiceBus oferece suporte à criptografia de mensagens por meio de um pacote separado, o NServiceBus.Encryption.MessageProperty.

Neste caso, porém, a criptografia é feita por propriedade, para reduzir seu impacto no desempenho. Isso significa que precisamos especificar quais propriedades do corpo da mensagem queremos criptografar.

Podemos habilitar a criptografia das propriedades da mensagem com o método EnableMessagePropertyEncryption():

using NServiceBus.Encryption.MessageProperty;

var encryptionService = new AesEncryptionService(
    encryptionKeyIdentifier: encryptionKeyId,
    key: Convert.FromBase64String(encryptionKey));

endpointConfiguration.EnableMessagePropertyEncryption(
    encryptionService: encryptionService,
    encryptedPropertyConvention: propertyInfo =>
        propertyInfo.Name.Equals(nameof(Message.Content))
);

Neste exemplo, as mensagens são criptografadas com o algoritmo AES, com base na chave de criptografia e no identificador fornecidos.

O método EnableMessagePropertyEncryption() instrui o NServiceBus a aplicar a criptografia a propriedades específicas da mensagem.

Ele aceita a instância encryptionService e um delegado de função que define a convenção para selecionar quais propriedades devem ser criptografadas. O objeto propertyInfo contém metadados sobre uma propriedade da mensagem, como nome, tipo e atributos. No nosso caso, criptografamos a propriedade Content da instância de Message.

Criptografia no MassTransit

O MassTransit também oferece opções para proteger as mensagens por meio da serialização.

Vejamos a configuração:

cfg.UseEncryption(Convert.FromBase64String(encryptionKey));

Simples assim: o pacote separado MassTransit.Newtonsoft, na mesma versão do MassTransit, oferece um método UseEncryption() que espera a chave de criptografia como um array de bytes, que obtemos decodificando uma string Base64.

Comunidade e suporte

O suporte da comunidade e os recursos disponíveis são tão importantes quanto as funcionalidades oferecidas, e podem influenciar muito o sucesso do nosso projeto a longo prazo.

De um lado, temos o Rebus, um projeto mantido pela comunidade, e o MassTransit v8, que continua sendo de código aberto, embora o fornecedor o declare sem suporte. Nos dois casos, há muitos recursos disponíveis online, incluindo tutoriais e exemplos.

Isso os torna uma ótima escolha para entusiastas de código aberto que preferem suporte colaborativo.

Do outro lado, o NServiceBus oferece suporte comercial por meio da Particular Software, com assistência profissional, treinamento, consultoria e documentação. Isso pode ser uma vantagem significativa para empresas que precisam de suporte garantido e de acordos de nível de serviço.

NServiceBus vs MassTransit: qual escolher?

Escolhemos o NServiceBus quando a organização está comprando um resultado, e não uma biblioteca, e o MassTransit quando a equipe quer ser dona da própria stack.

O NServiceBus traz as partes mais caras de construir internamente: o ServicePulse, para acompanhar a integridade dos endpoints em tempo real e fazer a análise forense do fluxo de mensagens, e um fornecedor com um contrato de suporte por trás de tudo isso. Esse pacote é cobrado por endpoint, então o custo cresce com a arquitetura, e não com a equipe.

O MassTransit cobre os mesmos recursos de mensageria (sagas, novas tentativas, outbox, requisição-resposta) sem interface operacional incluída (a v9.2 adiciona um painel em acesso antecipado). A versão 8 continua gratuita, sob Apache-2.0. A versão 9 é paga e tem código-fonte disponível, com um desconto de 100% para o qual organizações com receita inferior a US$ 1 milhão podem se qualificar. Portanto, a disputa é entre o NServiceBus e uma v8 sem suporte, esse desconto ou uma assinatura.

Para uma equipe de cinco pessoas que coloca em produção um único barramento de serviços, o MassTransit v8 ou o Rebus bastam. Para vinte equipes que precisam de alguém para quem ligar às 3 da manhã, é exatamente para o NServiceBus que o orçamento existe.

Comparação de código

Agora que conhecemos alguns recursos, vamos ver como enviar e receber mensagens com cada biblioteca.

Envio de mensagens com Rebus, NServiceBus e MassTransit

Enviar uma mensagem normalmente envolve criar um objeto de mensagem e despachá-lo. Vejamos como fazer isso com cada biblioteca.

Mas, antes disso, vamos definir uma interface comum:

public interface IMessageSender
{
    Task SendMessageAsync(Message message);
}

A interface IMessageSender define um método SendMessageAsync() que aceita uma instância da classe Message.

No Rebus, enviamos mensagens injetando a interface IBus na nossa classe e chamando o método Send().

Vamos definir uma classe RebusMessageSender:

using Rebus.Bus;

public class RebusMessageSender(IBus bus) : IMessageSender
{
    public async Task SendMessageAsync(Message message) =>
        await bus.Send(message);
}

Aqui, enviamos uma instância da classe Message usando a instância IBus. O Rebus roteia a mensagem para o destino adequado com base na configuração.

Com o NServiceBus, usamos IMessageSession ou IEndpointInstance para enviar mensagens.

Desta vez, vamos definir uma classe NServiceBusMessageSender para o NServiceBus:

public class NServiceBusMessageSender(IMessageSession messageSession) : IMessageSender
{
    public async Task SendMessageAsync(Message message) =>
        await messageSession.Send(message);
}

Neste exemplo, enviamos uma instância de Message usando a instância messageSession. O NServiceBus cuida do roteamento com base nos mapeamentos explícitos definidos na configuração do endpoint.

O MassTransit permite enviar ou publicar mensagens usando a interface IBus.

Por fim, vamos definir uma classe MassTransitMessageSender usando o MassTransit:

using MassTransit;

public class MassTransitMessageSender(IBus bus) : IMessageSender
{
    public async Task SendMessageAsync(Message message) =>
        await bus.Publish(message);
}

Usamos o método Publish() para enviar a mensagem a todos os assinantes interessados em Message.

Se quisermos enviar a mensagem para um endpoint específico, podemos usar o método Send() em vez disso, declarando a nova sobrecarga de SendMessageAsync() em uma interface própria, ICustomMessageSender:

using MassTransit;

public class MassTransitMessageSender(IBus bus, ISendEndpointProvider sendEndpointProvider)
    : IMessageSender, ICustomMessageSender
{
    public async Task SendMessageAsync(Message message) => 
        await bus.Publish(message);
    
    public async Task SendMessageAsync(Message message, string queueUri)
    {
        var sendEndpoint = await sendEndpointProvider.GetSendEndpoint(new Uri(queueUri));

        await sendEndpoint.Send(message);
    }
}

Neste exemplo, injetamos ISendEndpointProvider para obter uma referência a um endpoint específico. Em seguida, usamos o método GetSendEndpoint() com o URI da fila de destino para obter o endpoint. Por fim, usamos o método Send() para enviar a mensagem diretamente a esse endpoint.

Recebimento de mensagens com Rebus, NServiceBus e MassTransit

Receber mensagens envolve implementar handlers ou consumidores que processam as mensagens recebidas. Cada biblioteca define esses handlers à sua maneira.

Primeiro, vamos definir uma interface comum:

public interface IMessageHandler
{
    Task Handle(Message message);
}

A interface IMessageHandler define um método Handle() que aceita uma instância da classe Message.

Em seguida, vamos definir uma classe de handler compartilhada, que implementa a interface IMessageHandler e que os handlers de mensagens específicos vão invocar:

public class MessageHandler : IMessageHandler
{
    public Task Handle(Message message)
    {
        Console.WriteLine($"MessageId: {message.MessageId}, Content: {message.Content}");
        
        return Task.CompletedTask;
    }
}

Como podemos ver, o método Handle() imprime no console os detalhes das mensagens recebidas. Em uma aplicação real, porém, esse handler conteria a lógica de negócio.

No Rebus, implementamos a interface IHandleMessages<T> para o tipo de mensagem que queremos tratar. O Rebus descobre e registra os handlers automaticamente por meio da injeção de dependência:

using Rebus.Handlers;

public class RebusMessageHandler(IMessageHandler handler) : IHandleMessages<Message>
{
    public Task Handle(Message message) =>
        handler.Handle(message);
}

Neste exemplo, quando chega uma instância de Message, o Rebus invoca o método Handle().

No NServiceBus, implementamos uma interface IHandleMessages<T> semelhante:

public class NServiceBusMessageHandler(IMessageHandler handler) : IHandleMessages<Message>
{
    public Task Handle(Message message, IMessageHandlerContext context) => 
       handler.Handle(message);
}

O método Handle() recebe a mensagem e um IMessageHandlerContext, que oferece recursos adicionais, como enviar mensagens ou publicar eventos.

Vale notar que as mensagens que roteamos com o NServiceBus devem implementar a interface apropriada ou seguir a convenção.

Definimos a convenção de mensagens no arquivo Program.cs:

var conventions = endpointConfiguration.Conventions();
conventions.DefiningMessagesAs(type => type.Namespace == typeof(Message).Namespace);

Assim, definimos como mensagens todos os tipos que estão no mesmo namespace da classe Message.

No MassTransit, definimos um consumidor implementando a interface IConsumer<T>:

using MassTransit;

public class MassTransitMessageHandler(IMessageHandler handler) : IConsumer<Message>
{
    public Task Consume(ConsumeContext<Message> context)
    {
        var message = context.Message;

        return handler.Handle(message);
    }
}

O MassTransit usa o método Consume(), que fornece um ConsumeContext<T> com a mensagem e informações de contexto. Por meio desse contexto, podemos acessar cabeçalhos, publicar eventos ou interagir com o barramento de mensagens.

Embora os conceitos básicos sejam parecidos entre as bibliotecas, cada uma tem suas próprias convenções e padrões. O Rebus e o NServiceBus compartilham uma interface semelhante para tratar mensagens, enquanto o MassTransit usa o modelo de consumidor, centrado no contexto de consumo.

Qual dessas bibliotecas é de uso gratuito?

O Rebus tem licença MIT e é gratuito em produtos comerciais, sem limite de receita e sem taxa por endpoint.

O MassTransit mudou na versão 9, lançada em janeiro de 2026. A versão 8 continua sob Apache-2.0 permanentemente e ainda recebe novas versões, mas o fornecedor a considera sem suporte. A versão 9 é comercial, tem código-fonte disponível e exige uma chave de licença em tempo de execução. Organizações com receita bruta anual inferior a US$ 1 milhão podem se qualificar para um desconto de 100% que exclui o suporte comercial.

O NServiceBus é comercial, cobrado por endpoint lógico em produção, mas gratuito para desenvolvimento e gratuito em produção na edição Community: três endpoints, 10.000 mensagens por dia e suporte apenas pelo fórum (consultado em 13 de setembro de 2026).

Na hora de fazer o orçamento, é importante saber o que faz cada custo crescer. A licença do MassTransit se baseia nas linhas de produtos. O preço do NServiceBus se baseia na arquitetura, então dividir um serviço em dois endpoints muda a conta.

Hoje, a resposta gratuita é o Rebus em qualquer porte, o MassTransit v8 se pararmos de atualizar, o desconto da v9 ou do NServiceBus para pequenas empresas com menos de US$ 1 milhão e o NServiceBus dentro dos limites da edição Community. Se o custo for o critério decisivo, comece pelo Rebus.

Quais são as melhores alternativas ao MassTransit no .NET?

As três alternativas realistas ao MassTransit no .NET são o Rebus, o NServiceBus e continuar no MassTransit v8.

O Rebus é o substituto mais próximo, peça por peça. Tem licença MIT, lida com sagas, novas tentativas e outbox, e sua superfície de configuração é pequena o bastante para que uma migração consista, basicamente, em reescrever o código de registro e as assinaturas dos handlers.

O NServiceBus é a escolha certa quando o motivador é a operação, e não o custo da licença. Ele traz suas próprias ferramentas de monitoramento e um contrato de suporte, e o preço acompanha isso.

Continuar no MassTransit v8 é uma terceira opção legítima. A v8 continua sob Apache-2.0 permanentemente e a linha ainda recebe novas versões, mas o fornecedor a considera sem suporte e anunciou que a manutenção oficial se encerra após 2026, então essa opção ganha tempo em vez de resolver o problema.

Vale a pena conhecer o Wolverine se a equipe também quer o papel de mediador na mesma biblioteca, embora ele seja um projeto mais novo, com um histórico operacional menor. Seja qual for a escolha, os transportes que já usamos costumam reduzir a lista mais rápido do que qualquer comparação de recursos.

Nosso guia sobre a biblioteca Wolverine mostra como ela reúne os papéis de mediador e de barramento de serviços em um único pacote.

Conclusão

Comparamos os principais recursos, benefícios e casos de uso do Rebus, do NServiceBus e do MassTransit, e a escolha se resume ao custo de licenciamento, ao suporte a transportes e a quanto ferramental queremos receber pronto, em vez de construí-lo nós mesmos.

Cada biblioteca tem seus pontos fortes e se adapta a situações diferentes. Ao entender seus recursos e considerar fatores como licenciamento e custo, podemos tomar decisões bem fundamentadas, alinhadas aos requisitos da nossa aplicação e à experiência da nossa equipe.

Testado com .NET 10.0.10 e MassTransit 8.5.10, a versão mais recente da linha v8 sob Apache-2.0. O exemplo continua fixado na linha v8 gratuita, e não na v9 comercial com código-fonte disponível, que também exige uma chave de licença em tempo de execução em cada máquina.