Alternativas a MassTransit: Rebus y NServiceBus comparados

Rebus es la alternativa a MassTransit más sólida para la mayoría de los equipos .NET: tiene licencia MIT, es gratuito sea cual sea el tamaño de la empresa y es lo bastante pequeño como para leerlo en una tarde. NServiceBus es la alternativa a la que recurrir cuando lo que buscamos es comprar soporte y herramientas, no ahorrar dinero.

Si alguien busca una alternativa, es por un motivo comercial: a partir de la v9, MassTransit pasó a una licencia de pago y de código fuente disponible (source-available), así que las vías gratuitas son acogerse a un descuento del 100 % (al que pueden optar las organizaciones con ingresos inferiores a 1 millón de dólares), quedarse en la v8 o dejar de usarlo. Cuál de las tres bibliotecas encaja depende de los transportes, de la compatibilidad con sagas y del presupuesto. A continuación comparamos las tres en cada uno de estos aspectos.

Artículos relacionados: Publicar notificaciones de MediatR en paralelo · Cómo usar el patrón REPR en .NET

Presentación de los candidatos

Para la mensajería en .NET, Rebus, NServiceBus y MassTransit son las opciones principales, así que veamos qué ofrece cada una.

Primero, vamos a definir un mensaje sencillo:

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

Más adelante en el artículo, manejaremos mensajes de este tipo. Usamos un proyecto ASP.NET Core distinto para cada biblioteca, y cada proyecto incluye una copia de esta clase y de los tipos compartidos que definiremos después.

Rebus

Rebus es un bus de servicios ligero y de código abierto, centrado en la simplicidad y la facilidad de uso. Requiere una configuración mínima, lo que permite a los desarrolladores implementar sistemas de mensajería con rapidez.

El README de Rebus lo resume en una línea: “Rebus es una implementación ligera de bus de servicios para .NET”, construida con el menor número posible de dependencias.

La mayor ventaja de Rebus es su flexibilidad y su extensibilidad, que nos permiten adaptarlo a los requisitos específicos de nuestro proyecto.

Ahora, vamos a configurar 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>();

Aquí, configuramos Rebus para que use una capa de transporte en memoria y enrute a la cola designada todos los tipos de mensaje del ensamblado que contiene Message. 

Por último, el método AutoRegisterHandlersFromAssemblyOf<Program>() registra todos los handlers de nuestro ensamblado. Tanto este método como AddRebus() proceden del paquete Rebus.ServiceProvider.

En resumen, Rebus es ideal para aplicaciones pequeñas y medianas en las que la simplicidad y la facilidad de uso son prioritarias. Nuestra guía para empezar con Rebus en .NET recorre un primer proyecto de principio a fin.

NServiceBus

A continuación tenemos NServiceBus, un bus de servicios con numerosas funcionalidades, diseñado para aplicaciones de nivel empresarial. Ofrece capacidades avanzadas que lo hacen adecuado para sistemas empresariales a gran escala.

Lo que distingue a NServiceBus es su conjunto de herramientas de monitoreo y depuración, como ServicePulse y ServiceInsight, una aplicación de escritorio que Particular ha puesto en fase de retirada y que declarará obsoleta el 10 de febrero de 2027. Estas herramientas ofrecen visibilidad en tiempo real de nuestro sistema de mensajería, lo que facilita su mantenimiento y el diagnóstico de problemas.

Sin embargo, poner en marcha NServiceBus requiere más configuración que Rebus, aunque a cambio ofrece más control y un amplio conjunto de funcionalidades:

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;
});

En este ejemplo, configuramos NServiceBus para que use LearningTransport como capa de transporte y enrute las instancias de la clase Message al endpoint designado. El propio método UseNServiceBus() procede del paquete NServiceBus.Extensions.Hosting. NServiceBus 10.2 lo declara obsoleto en favor del método integrado AddNServiceBusEndpoint().

Gracias al sólido soporte comercial de Particular Software, NServiceBus es una opción excelente para aplicaciones empresariales de gran escala.

MassTransit

Por último, MassTransit es un bus de servicios centrado en la facilidad de uso y la flexibilidad. La versión 8 y las anteriores tienen licencia Apache-2.0, y la versión 9 es comercial y de código fuente disponible. La documentación de licencias de MassTransit es tajante sobre lo que esto significa: “MassTransit v9 (y posteriores) requiere una licencia para su uso, con la que obtienes un archivo de clave de licencia”.

MassTransit logra un equilibrio entre la simplicidad de Rebus y las funcionalidades avanzadas de NServiceBus, lo que lo convierte en una opción versátil para una gran variedad de aplicaciones.

Uno de los puntos fuertes de MassTransit son sus API de configuración fluida, que simplifican el proceso de configuración. También admite patrones de mensajería avanzados, como las sagas y las máquinas de estados:

using MassTransit;

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

Del mismo modo, configuramos MassTransit para que use una capa de transporte en memoria y definimos MassTransitMessageHandler como consumidor de mensajes.

MassTransit equilibra rendimiento y complejidad, lo que lo hace útil en aplicaciones medianas y grandes. Para verlo conectado a un bróker real, consulta nuestra guía sobre MassTransit con RabbitMQ en ASP.NET Core.

Transportes y protocolos admitidos

A continuación, veamos en qué se diferencian en cuanto a los transportes que admiten.

La elección del transporte puede influir mucho en nuestro sistema de mensajería, según la infraestructura que ya tengamos y los requisitos de rendimiento.

Veamos una comparación rápida de los transportes admitidos:

Como vemos, además de las opciones comunes, NServiceBus y Rebus también admiten MSMQ, aunque solo en .NET Framework, algo que puede beneficiar a sistemas heredados o a entornos que requieren protocolos de mensajería específicos. Si vamos a usar RabbitMQ, nuestra guía sobre RabbitMQ en ASP.NET Core explica cómo configurar el propio bróker.

Implementación de sagas

Gestionar procesos complejos y de larga duración suele requerir coordinar varios mensajes y mantener el estado a lo largo de distintos pasos.

Aquí es donde entran en juego las sagas. Las sagas son un patrón que ayuda a gestionar este tipo de flujos de trabajo, ya que garantiza la coherencia de los datos y orquesta la secuencia de operaciones.

En primer lugar, tenemos la saga basada en coreografía, en la que un bus de mensajes transfiere los mensajes entre productores y consumidores:

Como alternativa, podemos sustituir el bus de mensajes por un servicio especializado que orquesta la saga y obtener así una saga basada en orquestación:

Cabe destacar que las tres bibliotecas admiten ambas implementaciones del patrón saga.

Si quieres saber más sobre cómo implementar el patrón saga, consulta nuestros artículos sobre las implementaciones con NServiceBus y con Rebus.

Manejo de errores y reintentos

El manejo de errores es fundamental en cualquier sistema de mensajería, ya que garantiza que cada mensaje se procese incluso cuando surgen problemas inesperados. Cada biblioteca ofrece mecanismos distintos para manejar errores e implementar políticas de reintentos.

Manejo de errores y reintentos en Rebus

Rebus ofrece un enfoque sencillo para el manejo de errores y los reintentos de mensajes. De forma predeterminada, Rebus intenta procesar un mensaje varias veces antes de moverlo a una cola de errores. Este comportamiento garantiza que los problemas transitorios, como los fallos temporales de red o la contención de recursos, no provoquen la pérdida de mensajes.

Vamos a personalizar el comportamiento de los reintentos en Rebus con el método RetryStrategy(), encadenado después de Routing() en la llamada a AddRebus():

using Rebus.Retry.Simple;

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

En este ejemplo, la opción maxDeliveryAttempts controla cuántas veces intentará Rebus la entrega de forma inmediata. La opción secondLevelRetriesEnabled hace que Rebus vuelva a despachar el mensaje, envuelto en IFailed<Message>, cuando falla la primera tanda de intentos. Por último, errorQueueName define la cola de errores a la que se mueve el mensaje si fallan todos los intentos.

Es decir, los primeros intentos son reintentos inmediatos: Rebus vuelve a intentar procesar el mensaje enseguida y sin demora. Si fallan todos los intentos, los reintentos de segundo nivel entregan el mensaje a un handler de IFailed<Message>, que puede aplazarlo para un reintento diferido en lugar de moverlo de inmediato a la cola de errores.

Estas demoras permiten que se resuelvan condiciones temporales, como la inestabilidad de la red o la falta de disponibilidad de un servicio externo.

Manejo de errores y reintentos en NServiceBus

NServiceBus también ofrece mecanismos de reintento integrados que gestionan tanto los reintentos inmediatos como los diferidos.

Vamos a configurar tanto los reintentos inmediatos como los diferidos con los ajustes 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");

En este ejemplo, si el mensaje no se procesa correctamente, NServiceBus hará tres reintentos inmediatos y después dos reintentos diferidos, cada uno seguido de otra ronda de tres reintentos inmediatos. Si todos los reintentos fallan, NServiceBus moverá el mensaje a la cola de errores.

Además, NServiceBus nos permite implementar políticas de reintentos personalizadas mediante una política de recuperabilidad personalizada:

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

Como vemos, NServiceBus solo recurrirá al reintento inmediato en caso de una excepción TimeoutException, sin límite en el número de reintentos. En cualquier otro caso, redirigirá el mensaje a una cola de errores.

Manejo de errores y reintentos en MassTransit

MassTransit también ofrece un manejo de errores y unas capacidades de reintento flexibles a través de su middleware integrado. Nos permite configurar los reintentos con distintas estrategias, como reintentos inmediatos, intervalos y retroceso exponencial (exponential back-off).

Vamos a definir con MassTransit la política de reintentos de todos los endpoints:

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

En este ejemplo, Interval() indica que MassTransit debe reintentar el mensaje tres veces, con un intervalo de 2 segundos entre intentos. Si todos los reintentos fallan, MassTransit moverá el mensaje a una cola de errores.

MassTransit crea automáticamente las colas de errores añadiendo _error al final del nombre de cada endpoint.

Monitoreo e instrumentación

Monitorear el estado y el rendimiento de las aplicaciones es fundamental para detectar posibles problemas a tiempo. Cada biblioteca ofrece distintas herramientas e integraciones que nos ayudan a supervisar los sistemas.

Rebus y MassTransit se integran con frameworks de logging como Serilog, lo que nos permite capturar logs.

En comparación con Rebus y MassTransit, NServiceBus lleva el monitoreo más lejos con herramientas específicas como ServicePulse y, hasta febrero de 2027, ServiceInsight.

ServicePulse ofrece monitoreo en tiempo real de nuestros endpoints: destaca los mensajes fallidos y aporta información sobre el rendimiento del sistema.

ServiceInsight nos permite visualizar los flujos de mensajes y analizar a fondo el pipeline de procesamiento de mensajes, algo muy valioso para diagnosticar problemas complejos. ServicePulse también muestra los flujos de mensajes, y Particular recomienda migrar a él antes de que ServiceInsight quede obsoleto.

Además, todas las bibliotecas admiten OpenTelemetry, que podemos usar para recopilar métricas y enviarlas a nuestras herramientas de análisis preferidas, como Grafana o Prometheus.

Características de seguridad

La seguridad es lo más importante al transmitir mensajes entre servicios, sobre todo en sistemas distribuidos en los que los datos pueden atravesar redes no seguras. En los fragmentos de código siguientes, encryptionKey es una cadena que contiene una clave de 32 bytes codificada en Base64, y encryptionKeyId es una cadena que da nombre a esa clave para NServiceBus. Declaramos ambas en Program.cs, antes de la configuración del bus.

Cifrado en Rebus

Rebus permite proteger los mensajes durante el transporte y en reposo. Aprovecha las características de seguridad de los mecanismos de transporte subyacentes, como el cifrado SSL/TLS en protocolos como HTTPS o AMQP.

Veamos cómo habilitar el cifrado automático del cuerpo de los mensajes en Rebus, con una llamada más, encadenada a las anteriores:

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

El método EnableEncryption(), del espacio de nombres Rebus.Encryption, acepta una clave de cifrado codificada en Base64. De forma predeterminada, Rebus usa esta clave para cifrar el cuerpo de los mensajes con el algoritmo AES.

Si no proporcionamos una clave válida, Rebus lanza una excepción cuyo mensaje incluye una clave nueva, generada con la funcionalidad integrada de .NET, que podemos guardar en la configuración.

Debemos recordar que el cifrado se aplica solo al cuerpo del mensaje, mientras que los datos del encabezado del mensaje seguirán sin cifrar.

Cifrado en NServiceBus

Del mismo modo, NServiceBus admite el cifrado de mensajes mediante el paquete independiente NServiceBus.Encryption.MessageProperty.

Sin embargo, en este caso el cifrado se basa en propiedades para reducir su impacto en el rendimiento. Esto significa que debemos indicar qué propiedades del cuerpo del mensaje queremos cifrar.

Podemos habilitar el cifrado de las propiedades de los mensajes con el 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))
);

En este ejemplo, los mensajes se cifran con el algoritmo AES a partir de la clave de cifrado y el identificador proporcionados.

El método EnableMessagePropertyEncryption() indica a NServiceBus que aplique el cifrado a determinadas propiedades del mensaje.

Acepta la instancia encryptionService y un delegado de función que define la convención para seleccionar qué propiedades se deben cifrar. El objeto propertyInfo contiene metadatos sobre una propiedad del mensaje, como su nombre, su tipo y sus atributos. En nuestro caso, ciframos la propiedad Content de la instancia de Message.

Cifrado en MassTransit

MassTransit también ofrece opciones para proteger los mensajes mediante su serialización.

Vamos a configurarlo:

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

Así de fácil: el paquete independiente MassTransit.Newtonsoft, en la misma versión que MassTransit, proporciona un método UseEncryption() que espera la clave de cifrado como un array de bytes, que obtenemos al decodificar una cadena Base64.

Comunidad y soporte

El apoyo de la comunidad y los recursos disponibles son tan importantes como las funcionalidades que se ofrecen, ya que pueden influir mucho en el éxito a largo plazo de nuestro proyecto.

Por un lado, tenemos Rebus, un proyecto impulsado por la comunidad, y MassTransit v8, que sigue siendo de código abierto, aunque el proveedor lo considera sin soporte. En ambos casos, hay muchos recursos disponibles en línea, como tutoriales y ejemplos.

Esto los convierte en una gran opción para los entusiastas del código abierto que prefieren el soporte colaborativo.

Por otro lado, NServiceBus ofrece soporte comercial a través de Particular Software, con asistencia profesional, capacitación, consultoría y documentación. Esto puede ser una ventaja importante para las empresas que necesitan soporte garantizado y acuerdos de nivel de servicio.

NServiceBus vs MassTransit: ¿cuál conviene elegir?

Elegimos NServiceBus cuando la organización compra un resultado y no una biblioteca, y MassTransit cuando el equipo quiere controlar por sí mismo la pila tecnológica.

NServiceBus incluye las piezas que más cuesta construir por cuenta propia: ServicePulse para ver en tiempo real el estado de los endpoints y hacer el análisis forense de los flujos de mensajes, y un proveedor con un contrato de soporte que los respalda. Ese paquete tiene un precio por endpoint, así que el costo crece con la arquitectura y no con el equipo.

MassTransit abarca lo mismo en mensajería (sagas, reintentos, el outbox, solicitud-respuesta) sin una interfaz de operaciones incluida (la v9.2 añade un panel en acceso anticipado). La versión 8 mantiene la licencia Apache-2.0 y sigue siendo gratuita. La versión 9 es de pago y de código fuente disponible, con un descuento del 100 % al que pueden optar las organizaciones con ingresos inferiores a 1 millón de dólares. Así que la elección es NServiceBus frente a una v8 sin soporte, ese descuento o una suscripción.

Para un equipo de cinco personas que pone en marcha un único bus de servicios, basta con MassTransit v8 o Rebus. Para veinte equipos que necesitan a alguien a quien llamar a las 3 a. m., NServiceBus es justo aquello en lo que tiene sentido gastar el presupuesto.

Comparación de código

Ahora que conocemos algunas funcionalidades, veamos cómo enviar y recibir mensajes con cada biblioteca.

Envío de mensajes con Rebus, NServiceBus y MassTransit

Enviar un mensaje suele consistir en crear un objeto de mensaje y despacharlo. Veamos cómo hacerlo con cada biblioteca.

Pero antes, vamos a definir una interfaz común:

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

La interfaz IMessageSender define un método SendMessageAsync() que acepta una instancia de la clase Message.

En Rebus, enviamos mensajes inyectando la interfaz IBus en nuestra clase y llamando al método Send().

Vamos a definir una clase RebusMessageSender:

using Rebus.Bus;

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

Aquí, enviamos una instancia de la clase Message mediante la instancia de IBus. Rebus enruta el mensaje al destino adecuado según la configuración.

Con NServiceBus, usamos IMessageSession o IEndpointInstance para enviar mensajes.

Esta vez, vamos a definir una clase NServiceBusMessageSender para NServiceBus:

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

En este ejemplo, enviamos una instancia de Message mediante la instancia messageSession. NServiceBus se encarga del enrutamiento según las asignaciones explícitas definidas en la configuración del endpoint.

MassTransit nos permite enviar o publicar mensajes con la interfaz IBus.

Por último, vamos a definir una clase MassTransitMessageSender con MassTransit:

using MassTransit;

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

Usamos el método Publish() para enviar el mensaje a cualquier suscriptor interesado en Message.

Si queremos enviar el mensaje a un endpoint concreto, podemos usar en su lugar el método Send() y declarar la nueva sobrecarga de SendMessageAsync() en una interfaz ICustomMessageSender propia:

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);
    }
}

En este ejemplo, inyectamos ISendEndpointProvider para obtener una referencia a un endpoint concreto. Después, usamos el método GetSendEndpoint() con la URI de la cola de destino para obtener el endpoint. Por último, usamos el método Send() para enviar el mensaje directamente a ese endpoint.

Recepción de mensajes con Rebus, NServiceBus y MassTransit

Recibir mensajes implica implementar handlers o consumidores que procesen los mensajes entrantes. Cada biblioteca define estos handlers a su manera.

Primero, vamos a definir una interfaz común:

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

La interfaz IMessageHandler define un método Handle() que acepta una instancia de la clase Message.

A continuación, vamos a definir una clase de handler compartida que implementa la interfaz IMessageHandler y a la que invocarán los handlers de mensajes específicos:

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

Como vemos, el método Handle() imprime en la consola los detalles de los mensajes entrantes. Sin embargo, en una aplicación real, este handler contendría lógica de negocio.

En Rebus, implementamos la interfaz IHandleMessages<T> para el tipo de mensaje que queremos manejar. Rebus descubre y registra automáticamente los handlers mediante inyección de dependencias:

using Rebus.Handlers;

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

En este ejemplo, cuando llega una instancia de Message, Rebus invoca el método Handle().

En NServiceBus, implementamos una interfaz IHandleMessages<T> similar:

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

El método Handle() recibe el mensaje y un IMessageHandlerContext, que ofrece capacidades adicionales como enviar mensajes o publicar eventos.

Cabe destacar que los mensajes que enrutamos con NServiceBus deben implementar la interfaz adecuada o seguir la convención.

Definimos la convención de mensajes en el archivo Program.cs:

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

De esta forma, definimos como mensajes todos los tipos que están en el mismo espacio de nombres que la clase Message.

En MassTransit, definimos un consumidor implementando la interfaz 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);
    }
}

MassTransit usa el método Consume(), que proporciona un ConsumeContext<T> con el mensaje y la información de contexto. A través de este contexto, podemos acceder a los encabezados, publicar eventos o interactuar con el bus de mensajes.

Aunque los conceptos básicos son similares en todas las bibliotecas, cada una tiene sus propias convenciones y patrones. Rebus y NServiceBus comparten una interfaz similar para manejar mensajes, mientras que MassTransit usa el modelo de consumidor, centrado en el contexto de consumo.

¿Cuál de estas bibliotecas es gratuita?

Rebus tiene licencia MIT y es gratuito en productos comerciales, sin umbral de ingresos ni tarifa por endpoint.

MassTransit cambió con la versión 9, publicada en enero de 2026. La versión 8 conserva la licencia Apache-2.0 de forma permanente y sigue publicándose, pero el proveedor la considera sin soporte. La versión 9 es comercial y de código fuente disponible, necesita una clave de licencia en tiempo de ejecución, y las organizaciones con ingresos brutos anuales inferiores a 1 millón de dólares pueden optar a un descuento del 100 % que excluye el soporte comercial.

NServiceBus es comercial, con un precio por endpoint lógico en producción, pero es gratuito para desarrollo, y también en producción con su edición Community: tres endpoints, 10 000 mensajes al día y soporte solo a través del foro (consultado el 13 de septiembre de 2026).

A la hora de presupuestar, importa saber con qué crece cada costo. La licencia de MassTransit se basa en las líneas de producto. La de NServiceBus se basa en la arquitectura, así que dividir un servicio en dos endpoints cambia la factura.

Hoy, las opciones gratuitas son Rebus, sea cual sea el tamaño; MassTransit v8, si dejamos de actualizar; el descuento para pequeñas empresas de la v9 o de NServiceBus, por debajo de 1 millón de dólares, y NServiceBus, dentro de los límites de la edición Community. Si lo que decide es el costo, empieza por Rebus.

¿Cuáles son las mejores alternativas a MassTransit en .NET?

Las tres alternativas realistas a MassTransit en .NET son Rebus, NServiceBus y quedarse en MassTransit v8.

Rebus es el sustituto más directo. Tiene licencia MIT, gestiona sagas, reintentos y el outbox, y su superficie de configuración es lo bastante pequeña como para que una migración consista sobre todo en reescribir el código de registro y las firmas de los handlers.

NServiceBus es la opción cuando lo que impulsa el cambio son las operaciones y no el costo de la licencia. Incluye sus propias herramientas de monitoreo y un contrato de soporte, y su precio está en consonancia.

Quedarse en MassTransit v8 es una tercera opción legítima. La v8 conserva la licencia Apache-2.0 de forma permanente y sigue publicándose, pero el proveedor la considera sin soporte y ha anunciado que el mantenimiento oficial no se extenderá más allá de 2026, así que sirve para ganar tiempo, no para resolver el problema.

Wolverine merece un vistazo para los equipos que también quieren cubrir el papel de mediador con la misma biblioteca, aunque es un proyecto más joven y con menos trayectoria en producción. Elijamos la que elijamos, los transportes que ya usamos suelen acotar la lista más rápido que cualquier comparación de funcionalidades.

En nuestra guía sobre la biblioteca Wolverine mostramos cómo reúne las funciones de mediador y de bus de servicios en un solo paquete.

Conclusión

Hemos comparado las características clave, las ventajas y los casos de uso de Rebus, NServiceBus y MassTransit, y la elección se reduce al costo de la licencia, a los transportes admitidos y a cuántas herramientas queremos tener ya incluidas en lugar de construirlas nosotros mismos.

Cada biblioteca tiene sus puntos fuertes y se adapta a casos distintos. Si entendemos sus capacidades y tenemos en cuenta factores como la licencia y el costo, podemos tomar decisiones fundamentadas que se ajusten a los requisitos de nuestra aplicación y a la experiencia de nuestro equipo.

Probado con .NET 10.0.10 y MassTransit 8.5.10, la última versión v8 con licencia Apache-2.0. El ejemplo se mantiene fijado a la rama v8 gratuita, y no a la v9, comercial y de código fuente disponible, que además necesita una clave de licencia en tiempo de ejecución en cada máquina.