Multi-tenant Application

Multi-tenancy is an architecture in which a single instance of a software application runs on a server and serves multiple customers. Each customer is called a tenant.

Multi-tenancy can be economical because software development and maintenance costs are shared. It can be contrasted with single-tenancy, an architecture in which each customer has their own software instance and may be given access to code. With a multi-tenancy architecture, the provider only has to make updates once. With single-tenancy architecture, the provider has to touch multiple instances of the software in order to make updates.

Figure 1: Multi-tenant Architecture

Figure 2 : Detail overview of multi-tenant application architecture

A multi-tenant application needs to be carefully designed in order to avoid major problems. It:

needs to detect the client (or tenant) that any individual web request is for;
must separate persistent data for each tenant and its users;
has to segregate configuration for each tenant;
cannot allow cached data (e.g. views) to leak between tenants;
requires separate background tasks for each tenant;
must identify to which tenant each line of log output belongs.

Figure 3 : Single-tenant and multi-tenant application

Advantages of Multi-tenant application

1. REDUCED MAINTENANCE COSTS

A multi-tenant application is a single codebase, installed in a single location (a single server or pool of servers), and potentially relying on a single instance of each backing service (cache, database, log, etc.). When an end-user reports an error, developers don't need to determine first on which instance the error occurred before replicating and debugging. A single source of application logs helps here, too. And when a fix is ready, it gets committed into the (only) repository, and re-deployed to the (only) server/pool – so all tenants benefit from the fix immediately and simultaneously.

2. NCREASED SCALABILITY

Imagine a situation where an application is set up for two clients, and each client generates about 1.5 server's worth of load. If the application is deployed separately for each client, it takes four servers (two each) to handle the total load. On the other hand, a multi-tenant application could be installed on just three instances to handle the same load. With more tenants, the advantages of a multi-tenant architecture grow even further.

Disadvantages of Multi-tenant application

1. INCREASED COMPLEXITY

A single-tenant application is simpler than the equivalent multi-tenant app. There doesn't need to be any code to protect against data leakage between tenants, or to detect which tenant a web request is intended for. Its configuration can be essentially static. With a separate instance of the application for each client, logs are segregated, so the log format can be simpler.

2. REDUCED DISTRIBUTION OF RISK

By running on a single server (or pool), backed by a single database, a multi-tenant app has fewer points of failure – but those failure points have a greater effect. When a single-tenant application instance breaks (say, the database goes down), it brings down a single tenant; other instances are able to continue unaffected. When the database for a multi-tenant app is unavailable, all tenants experience loss of service.

3. REDUCED FLEXIBILITY ACROSS TENANTS

A single-tenant, multi-instance app has greater flexibility to set low-level configurations (of the server hardware or OS, or of the web server, or the application itself) than a multi-tenant app. This won't be a problem for many applications, but if the application needs a high degree of customization for each new tenant, a multi-tenant app might not be the best solution.