Tag Archives: NServiceBus

Introduction to NServiceBus

Why NServiceBus?

Simply put, NServiceBus elegantly solves the “reliability” part of the high-performing scalable distributed system architecture.  Think about for a moment that you architected, designed and developed a high end system which is highly scalable, available, extensible etc. but is less reliable, how big will be the success of the system, its highly questionable. Reliability of a system is crucial to gain credibility from the customer which will lead to big success. In addition to reliability, you can achieve highly scalable, extensible, available applications by incorporating NServiceBus in your SOA based distributed system.

Say for example you architected an online book store application and in order to provide high scalability you designed separate subsystems to process Ordering, Billing and shipping as follows.


UI portal depends on Ordering system to populate cart and do checkout, ordering system talks to billing to bill the customer and after billing to goes to shipping in order to deliver the product to the customer.  All these subsystems are loosely coupled and hosted on its own server to provide high scalability and extensibility etc,. Now although you implemented high availability and disaster recovery solutions to all the subsystems and you expect it to be highly available but still there is chance that system will become unavailable in an extreme case like network down, system reboot due to patch installation or system crash. In a distributed systems world, our systems sometimes depends on services from third party providers and what if their systems unavailable during an important transaction, you will end up losing the revenue from that transaction.

I personally encountered this problem on a famous online portal, firstcry.com who is specialized in baby products. I ordered some bath products for my baby and when I ordered there were only a very few quantities left in the stock so I ordered them quickly. I did a perfect checkout entering all the details including my card details. Amount got debited from my card. But when I am taken back to their order status page from my third party card payment page, there waited a surprise for me. Order status stated payment not yet received. How come this can be? I entered all the details correctly, it was a perfect checkout and I received even a sms from my credit card provider that amount got debited.  I called firstcry.com and they said “sorry sir, but payment not yet received you have to wait 24 hours to learn what happened and to process your order”. That’s unacceptable. But still I waited 24 hours patiently and then I received a call from them saying “Now we received payment but sorry sir, we are now out of stocks on those products you ordered”. That’s intolerable. Since there were only less quantity when I made order and by the time payment received them (which took 24 hours in my case), products gone out of stock, somebody else bought it and I got to get my money returned. They lost the revenue from that transaction and worst of all they lost customer’s trust, which will lead me not to go them for future transactions. From the situation it’s clear that some system went down or not in sync or not did a reliable transaction while I made order. I wish they needed a Service Bus to connect their sub systems reliably.

How NServiceBus achieves reliability?

Traditional distributed systems are designed as Request/Response system; i.e client makes a request to the server for a service and waits for the response. Server processes the request and sends the response to the client. Client process is blocked till it gets the response from server as it’s a synchronous processing. Since its synchronous processing and when one of communication is down, the whole transaction will be failed. But NServiceBus uses Message based communication using any messaging queues like MSMQ, RabbitQ etc. NServiceBus provides reliable communication using Message queue and asynchronous processing, implementing following principles.

1. Store and forward Messaging.

store and forward

Store and forward follows “fire and forget” strategy by client making request to server asynchronously and immediately returns control to the calling process. Request message can be stored locally at the client side before sending it to server. So before that request reaches server if server crashes or down, the request won’t be lost as it’s stored at the client side queue storage and that request will be retried sending to server automatically till it reaches server successfully.  Even if server crashes after the request received and stored at the server queue but did not processed successfully, that request will be processed after server is up and ready to process. This strategy exposes two benefits. 1. Client server communication is reliable through asynchronous messaging. 2. Since it follows ‘fire and forget’ approach, once request is made at the client side, control is returned immediately thereby releasing all the client resources like client thread and memory etc tied up with that request.

2. Request/Response & One way messaging.

request response

Unlike traditional synchronous request/response processing, NServiceBus implements request/response message processing as two one-way asynchronous processing. One asynchronous request is from client to server for making request. Another one is from server to client for sending response. Again, this exhibits all the benefits exposed by store and forward strategy.

3. Publish/Subscribe messaging.


Publish/Subscribe strategy helps build the distributed system extremely loosely coupled and each system have no knowledge about the other systems purpose of existence. Pub/Sub always works like there will be multiple subscribers and one publisher. All subscribers will be interested on a certain message which will be published by the publisher. Initially all subscribers must subscribe to publishers exposing its interest for a certain message. In addition to subscription message, each subscriber has to send its respective endpoint to which publisher has to deliver published message. The same way, subscriber has to know the publisher endpoint to which it has to subscribe.