In the article talking about SLAs I mentioned two strategies Northwind hosting can use to manage performance and scalability of the hosted application:

  1. Adding new servers to host web services, with a front load balancer
  2. Doing "database load balancing" per tenant

#1 is obvious. NWH canonical architecture is designed to support this scalability strategy. #2 is not as obvious. NWH is a SaaS hoster and as such is aware of typical SaaS idiosyncrasies: for example the notion of "tenants" and "multi-tenant" applications.

Actually, their application manifest surfaces this concept and captures that information. There are two fields requested at the application level that allow NWH to do some magic at the database level:

  • Average DB size / tenant.
  • A flag to characterize the application as multitenant or not. 

The first one is used for growth estimation and therefore raw storage allocation. The second one has deeper implications.    

When the IsMultitenant flag is set to true, NWH interprets and expects these things to happen:

  • The call context of all Operations will have "Tenant_Id" available for inspection. This is an "out of band" signal that the infrastructure has access to.
  • Databases can be split at the tenant level without compromising system integrity.

LitwareHR actually complies with these requirements, and therefore its manifest will set IsMultitenant to true.

What NWH can do now is essentially create identical databases and distribute tenants to different servers as they are provisioned (Figure 1).

NWH-DB-TENANT-LDB    

Figure 1: DB load balancing based on tenant id

Again, this can be done with no impact on the application, because the data access has been standardized on Enterprise Library and the compliance of LitwareHR to the hosting platform is high.

LitwareHR will make the calls to the database as usual, and all the logic of translating the logical DB name to the actual one is done behind the scenes in NWH extensions to Enterprise Library:

NWH-DB-TENANT-LDB-EL-CODE

NWH has the ability to move tenants to different databases transparently based on different usage patterns (e.g. tenants with thousands of records might get bigger servers, many tenants with few records might all get stashed in one machine, etc.), making the best use of the underlying platform (SQL) being the ultimate goal.