Multitenant Application example:

Let us take an example of an application that can be deployed in a single tenant mode and a multitenant mode. In a multitenant deployment, the information about the application is stored in a separate database. The customer’s data is stored in a separate business database, each of which is a tenant in the deployment. By separating application from data, the same stack can be deployed to many customers with centralized maintenance of the application and the isolation of each tenant.  The application database contains the tables that define an application.

If there are ten customers to the current solution, each of them can get a tenant database dedicated to store the company’s business data. The knowledge about the shared application is then stored in a dedicated application database. When this solution is upgraded but the deployment mode is not changed, we can still have a single database that has one or more companies in it. We can also choose to extract the application tables to an application database but still have one business data database that has one or more companies in it. In both scenarios, we have not migrated to multitenancy, but in the second scenario, we have prepared our solution so that we can move to multitenancy at a later point.

When a multitenant solution is deployed, a relationship is activated between the server instance by mounting the tenant to the instance. Similarly, to disconnect a tenant, the dismount needs to be performed. When the tenants are mounted, the tenant configuration is stored in the tenants table of the application database that is connected to the instance. If we connect additional server instances to the same application database, then the server instances will automatically inherit the tenant configurations from the application database. This means that the existing tenants will be automatically mounted to the new server instance.  If we mount or dismount an instance, then we have to perform the operation on one of the instances. The other instances will automatically detect and update the changes.

When we refer to a tenant, we refer to it by the tenant ID but it is also possible to refer to them by the hostnames for the tenants in the deployment. A tenant specific sub-domain is setup in this case. The tenant host name, mytenant.myservice.com must be specified as an alternative in the tenant configuration.  The URL can specify the tenant ID and the tenant host name if we specify the hostnames as an alternative IDs for tenants.