NSBCon London 2014

The following post was co-authored with Roy Cornelissen, who can be found at WordPress and Twitter.

On June 26th we will be speaking at NSBCon in London. This post gives you a quick glimpse of the topics we will try to cover in out session.

Where we started

Before bringing in NServiceBus, we were dealing with a traditional 3-tier ASP.NET web application: a Silverlight front end talking to a WCF back end talking to a database. As the functionality of the application grew more complex and richer, the webservice operations became bigger and took longer to finish. Combined with the fact that we were increasing the number of customers working on the same SaaS platform, each producing more data and larger databases, we were facing an exponentially growing performance and scalability problem.

One of the problems that come up when building systems with a purely traditional N-tier architecture, is that it gets harder and harder to separate responsibilities. After all, everything needs to happen within that single webservice request, leading to code entanglement and a mixup of responsibilities.

Discovering NServiceBus

We were certain that the existing code base wasn’t going to scale enough to meet our growth requirements. At the same time, we had clear logical boundaries in our system that we had already identified. We started drawing those boundaries and plotting responsibilities of different parts of the software into these boundaries. From a process angle, we started seeing clear separations where we could put in messaging to enable asynchronous execution of several (sub)processes.

A perfect fit for NServiceBus, which we started implementing in small steps.

Along the way, we learned quite a few things, about which we will be speaking at NSBCon in London on June 26th. Some of the best practices we’ll cover include:

Multi-tenancy

In a multi-tenant environment like our SaaS solution, how do you deal with messages flowing through the system for all different tenants all at once? How do you make sure that the data ends up in the correct database? And how do you make sure that one tenant doesn’t suffer from another tenant’s excessive load on the system?

Mapping Sagas to logical properties

When we started implementing Sagas, we quickly started seeing the need to map the persisted Saga data on more than just one single unique property. There are several approaches for this, such as concatenating properties into one “mapping property”, or generating a technical unique value, but none of these seemed very maintainable for us.

Mark has written about this earlier in this very blog. In our talk, we’ll walk through how we implemented this feature on top of existing RavenDb persistence.

Keep your transactions on a strict diet

You could imagine what happens if you start putting big chunks of code into NServiceBus handlers and start executing them asynchronously. This isn’t going to help your system’s throughput a lot if the transactions are still very long. We’ll look at some things you need to think about when adding asynchrony to your system.

Some other topics

Other than the three topics mentioned above, we will share some additional lessons we learned while adjusting our software to properly utilize NServiceBus.

In Conclusion

NSBCon promises to be an exciting event. We are honored to be listed as speakers amongst a great line-up. Be sure to grab a ticket at www.NSBCon.com!

See you in London!