Multi-Tenant Data Architecture

Multi-tenancy Models

When any application planned to roll out for multiple regions/countries/clients then multi-tenancy model comes into picture. This can be classified into four models as below

-       Separate Application Separate Database
-       One Shared Application and Separate Database
-       One Shared Application and Shared Database (Separate Schema)
-       One Shared Application and Shared Database (Same Schema)

These models are differentiated based on whether the data is isolated or shared. The difference between the shared data and the isolated data is a continuum with many variations that are possible.


Sample Application URL for different implementations.

Tenant Name
URL
Tenant 1
Tenant1.domainname.com
Tenant 2
Tenant2.domainname.com
Tenant 3
Tenant3.domainname.com

Tenant can be a Region or Country or Client.

Why single URL multi-tenant model is not recommended?

-       Single Application with multiple subdomains will be added
-       Logical access point per tenant to the application will be achieved
-       Tenant specific customisation is possible even before login by the user
-       If a user is accessible to multiple tenants then the application will have option to switch between the tenants

Separate Application Separate Database

Storing tenant data in separate database is the simplest approach to data isolation. In this model, we will be having separate application for each region/country to whom we plan to roll-out the application. We may be having multiple applications deployed in multiple regions and / or servers. Same code base will be deployed into multiple applications.


Pros 

·         Since each region has its own instance, data will be isolated.
·         Data can be stored in the same country/region for which the site is rolled out.
·         Some countries will have an additional requirement of having physical db server with in the country.
·         If we have heavy load to the application in one region then the performance of the application will not be affected in other regions.
In the event of failure, if a single tenant data needs to be reloaded from backup then it is possible.

Cons 

·         Managing the multiple instances of the application is cost and effort bound.
·         Cost involved in each rollout in respect to hardware, licencing and implementation.
·         Cost involved in each upgrade to the application as we have multiple instances.
·         More testing is involved at various stages of rollouts to the different clients.
·         Lead to higher costs for maintaining equipment and backing up tenant data.
        

One Shared Application and Separate Database

 Storing tenant data in separate database is the simplest approach to data isolation. In this model, there will be one application deployed and multiple databases will be pointed based on the tenant.


Pros

·         Since each region has its own database instance, data will be secured separately in the same server
·         Database security prevents any tenant from accidentally or maliciously accessing other tenants' data
·         In the event of failure, if a single tenant data needs to be reloaded from backup then it is possible.

Cons

·         If we have heavy load to the application in one region then the performance of the application will affect in the other regions as we have a single instance. However, this can be avoided by scaling the servers as per the demand arises.
·         Lead to higher costs for maintaining equipment and backing up tenant data

One Shared Application and Shared Database (Separate Schema)

Another approach involves hosting multiple tenants in the same database, with each tenant having its own set of tables that are grouped into a schema created specifically for the tenant. This approach offers a moderate degree of logical data isolation for security-conscious tenants

Pros

·         Single database server can accommodate more clients and the cost per client will reduce in this approach
·         This approach suits for tenants who likes to have mix of data isolation and shared

Cons

·         If we have heavy load to the application in one region then the performance of the application will affect in the other regions as we have a single instance. However, this can be avoided by scaling the servers as per the demand arises.
·         Logical separation of data is not possible and so application holds the responsibility for Database security which prevents any tenant from accidentally or maliciously accessing other tenants' data
·         In the event of failure, if a tenant data needs to reload from backup then it is not possible. The whole database needs to be reloaded.

One Shared Application and Shared Database (Same Schema)

Another approach involves hosting multiple tenants in the same database, all tenants will share the same schema as well. Each tenant will hold  the tenant id next to each record in the database. This approach offers a moderate degree of logical data isolation for security-conscious tenants.



Sample tables

Pros

·         Single database server can accommodate more clients and the cost per client will reduce in this approach
·         This approach suits for tenants who likes to have mix of data isolation and shared

Cons

·         If we have heavy load to the application in one region then the performance of the application will affect in the other regions as we have a single instance. However, this can be avoided by scaling the servers as per the demand arises.
·         Logical separation of data is not possible and so application holds the responsibility for Database security which prevents any tenant from accidentally or maliciously accessing other tenants' data
·         In the event of failure, if a tenant data needs to reload from backup then it is not possible. The whole database needs to be reload.

Conclusion


When we have large number of tenants, we can choose the Shared Application and Shared Database approach. If we are planning to make adhoc customization per tenant then we can choose the Separate Application Separate Database approach.

Apart from these we may also need to consider on these items

·         Economic Considerations
·         Security Considerations
·         Regulatory Considerations


Location: Singapore

Comments

Post a Comment

Popular posts from this blog

Error : ID4243: Could not create a SecurityToken.

For persons who worked on WIF Programming would encounter the following error, ID4243: Could not create a SecurityToken. A token was not found in the token cache and no cookie was found in the context We will be getting this error when the browser sends the cookie to the server and when sever validates the token and it fails then we may get this error. The end user can't do anything since the browser sends the token to the server always until the user manually clears the cookie from the browser. To handle this scenario we can srite the below list of code in the Global.asax.cs Basically, what it does is it will check for the excetion type and then it tries to sign out the user (delete the cookie informations) and redirect to the requested page. It is as simple as it is :) protected void Application_OnError() { var ex = Context.Error; if (!(ex is SecurityTokenException)) return; Context.ClearError(); if (FederatedAuthenticati...
Read more

MVC - Looping through the model properties from cshtml

When ever we are struck with the values being not properly filled in the model and need to print all the properties of the model or dto of the page then we can use the below lines of code to loop through the model or dto and write all the items in the page. foreach (var result in Model)             {                                   var type = result.GetType();                     var properties = type.GetProperties();                     <ul>                         @foreach (var property in properties)                         {                         <li>     ...
Read more