Messaging Framework Comparisons - NServiceBus

Part 4 of 4

Messaging frameworks allow for the creation of loosely coupled, highly resilient, and highly scalable systems. The challenges faced by modern applications are complex, and our solutions are likewise sophisticated. Applying patterns help us to design modern applications while reducing complexity. Messaging is a reliable and proven pattern to address these needs.

This blog series exists to survey messaging frameworks and comparable technologies built on the .NET stack. While there are quite a few options in this space when working with .NET, this series narrows its scope to the following: NServiceBus (, Microsoft Azure Service Bus (, and Akka.NET (

  • The Intro to this series can be found here.
  • Part 2 of this series – Azure Service Bus – can be found here
  • Part 3 of this series – Akka.NET – can be found here.



NServiceBus originally started as an open-source project, eventually moving to a licensed model as adoption grew and the need for more commercial support increased. Of the messaging frameworks in this document, NServiceBus is the most mature and fully-featured.

NServiceBus is an enterprise service bus that runs over a variety of transports, such as MSMQ and Azure Storage Queues. Support for running on-prem or in Azure is also supported.

The primary goals of NServiceBus is to provide as much of the typical messaging infrastructure for you, lowering development time and time to market.


NServiceBus implements resiliency through a baked-in first and second-level retry mechanism. After all retries are exhausted, any transaction your message is enrolled in will be rolled back and a copy of the message will be sent to a configurable error queue. Custom recoverability strategies can also be implemented.

Another feature of NServiceBus is guaranteed message durability and delivery. Two-phase commits are used in order to ensure messages will not be lost.


The NServiceBus host can be either embedded in your application or configured to run as a windows service. When self-hosted, deployments follow whichever deployment strategy your system normally follows. For services hosted under a windows service, you would follow the typical process of stopping, replacing, then restarting the host.

When deploying non-scaling services, due to guaranteed message durability, there is no need to wait for queue drains to occur. This changes, however, when deploying services that are scaled using either the distributor or the sender-side model. In this case, care must be taken to properly decommission and drain endpoints.


In previous versions of the framework, NServiceBus implemented scaling through the use of distributors, which were capable of routing to available worker nodes, similar to a load balancer. For high availability, the distributor was typically set up to use failover clustering.

With the latest release of NServiceBus, scalability has changed to sender-side distribution, whereas the sender is aware of nodes that can process its messages and distributes them in a round-robin manner.

Throughput with NServiceBus is lower than the other frameworks, due to the amount of infrastructure wrapping the system. Built-in features such as automatic retries, durability, delivery guarantees, and exactly-once delivery lower the throughput speed, at the trade-off of a system “that just works”.


The design of NServiceBus abstracts away the majority of the most difficult concepts in an enterprise service bus. While there are pitfalls that can affect any poorly designed architecture, NServiceBus alleviates the majority of these hurdles for you.


In this category, NServiceBus is a clear winner. NServiceBus has a suite of products custom-built for monitoring message flow and errors, as well as providing insight into a variety of metrics.


Costs for NServiceBus licenses follow a recurring monthly model and are charged either per developer or per node, depending upon the type of environment you’re deploying onto. More details can be found here.


NServiceBus provides customer support based on the number of incidents needed per month, as well as the required speed in of turnaround time. These correlate to higher tier monthly fees.

Lancelot Dunnehoo

Lancelot Dunnehoo

Lance Dunnehoo is AI‘s Chief Architect and Principal Cat Herder. His 17 years in software consulting has led to a broad depth of knowledge in many technical and business domains, but his primary passion lies in distributed architecture and systems integration. When he‘s not working he can typically be found..working.