Category Archives: Architecture

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, 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 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.



Trello Architecture

Trello is a state of the art technology website developed by Fog creek software for managing anything (be it personal tasks, Vacation planning, project planning etc.) collaboratively by a group of people or individual.

This is how the application is designed and working:

Trello Arch

  1. Trello is a Single-page app that would generate its UI on the client and accept data updates from a push channel.
  2. They use CoffeeScript which does all the client side functionalities.
  3. The main client side technologies other than CoffeeScript:
    i)    Backbone.js (client-side MVC).
    ii)    HTML 5 pushState
    iii)    Mustache (templating language)

4.    Trello servers serve virtually no HTML, In fact, they don’t serve much client-side code at all. Since it’s a single-page app, a single minified and compressed approx 250K app is downloaded initially in the form of JS file, after that everything else is asynchronous.
5.    Initial single minified/compressed js file contains third party libraries, compiled CoffeeScript and Mustache templates and a CSS file (Compiled from LESS source with inlined images).
6.    This minified initial file is served through CloudFront CDN, so initial load of the app is fast irrespective of geographic location.
7.    In parallel, Trello kicks off an AJAX data load for the first pages data content and try to establish a HTML 5 websocket connection to the server.
8.    After data is returned from server through Ajax call, Backbone.js is in play to bind the data to DOM and display the content, just like our Knockout.js.
9.    There won’t be any page transition from one page to another after full initial page is loaded. HTML 5 PushState is used to move between pages and to provide consistent links in the location bar and just load data for backbone based script to handle transition.
10.    To represent HTML as client side model, Mustache is used as a templating language.
11.    When there is browser support on HTML 5 websocket (chrome, firefox and safari), websocket connection is made so that server can push changes made by other people down to browsers listening on the appropriate channels. So when anything happens to a board you are watching that action is published to trello server processes and propagated to your watching browser with very minimum delay, usually under a second.
12.    When browser don’t support websockets (browser like IE), they use AJAX requests to get updates every couple of seconds while user is active, and back off to polling every 10 seconds when the user goes idle.
13.    Major server side technologies are:
i)    Node.js ( server side technology)
ii)    Redis (To share data between users at the server)
iii)    MongoDB (Database )

14.    Server side of Trello is mostly built using Node.js. Trello wanted instant propagation of updates, which meant that they needed to be able to hold lot of open connections, so an event-driven, non-blocking server seemed a good choice, so they chose node.js.
15.    Client simply invoked those functions written in node.js throw a thin wrapper over a websocket.
16.    Trello uses Redis for data that needs to be shared between server processes but not persisted to disk.
17.    Interesting use of Redis is for sending changes to Models down to browser clients. When an object is changed on the server, they send a JSON message down all the appropriate WebSockets to notify those clients, and store the same message in a fixed-length list for the affected model, noting how many messages have been added to that list over all time. Then, when a client that is on AJAX polling pings the server to see if any changes have been made to an object since its last poll, they can get the entire server-side response down to client.
18.    Since trello have to work extremely fast, they used MongoDB to store data permanently.
19.    MongoDB is a documents database, so it stores a trello card’s data in a single document.