Multi-tenant applications excel at serving multiple tenants with a single set of code. The architecture can serve many different clients or tenants with a single code source. What are the general building ideas for multi-tenant systems?

1. What is a tenant

In a multi-tenant architecture, an instance of an application can be used to provide access to the application to a group of users called customers or tenants. A tenant consists of a group of users who share the same data, configuration information, and user management information. Each tenant has a specific identity, and the application should be capable enough to respond differently to each tenant.

It should be noted that in a multi-tenant architecture, each tenant is physically integrated but logically separated from each other. Each tenant may even be physically isolated from others.

Tenants share access to the hardware and are able to customize certain parts of the application – this can be the look and style of the user interface, or even business rules, but of course tenants cannot customize the source code of the application.

2. What is single-tenant architecture?

A single-tenant architecture is built on a common code base in which a single application instance can serve a single customer or tenant. In contrast to multi-tenant applications, in single-tenant applications, each tenant maintains its own copy of the database and application instance.

Single-tenant applications are considered reliable and you can quickly restore data if it is lost due to a disaster. If a data breach occurs for one tenant, the other tenants are not affected because they use separate instances of the application. Tenants can also choose when to install updates.

Customizing, setting up, maintaining, and upgrading single-tenant applications can be expensive in terms of time and money. Although single-tenant applications have access to a large number of resources and can be easily customized, regular maintenance and management of such applications can be a daunting task. Because only one customer is paying for your application, this can be costly.

3. What is multi-tenant architecture?

Multi-tenancy is a software architecture in which application instances are shared among multiple tenants of the application, each with its own account, isolated for performance, data security, and so on.

Multi-tenancy is an ideal architecture to leverage the cloud environment in the best way. In essence, it provides a shared platform that you can use to take full advantage of the cloud infrastructure — it evolves to keep pace with the needs of all tenants using the application.

Multi-tenant applications can share the same resources with multiple tenants while still being modular and extensible, thus improving stability and significantly reducing development and deployment costs.

4. Multi-tenant architecture: Benefits

The benefits of a multi-tenant architecture are:

  • Easy to get started: Multi-tenant architecture is ideal for applications that require an easier startup experience or easy to get started with fewer hardware requirements.
  • Maintenance: Ease of maintenance is an advantage of multi-tenant applications.
  • Cost reduction: In contrast to single-tenant architectures, multi-tenant architectures are relatively inexpensive due to shared infrastructure, helping to build applications with lower maintenance costs and better computing power.
  • Resource usage: A multi-tenant architecture ensures better utilization of available resources than a single-tenant architecture.
  • Upgrading is easier: In multi-tenant applications, upgrading is seamless and relatively simple.

5. Multi-tenant architecture: Disadvantages

Potential disadvantages of a multi-tenant architecture are:

  • Isolation: You need to isolate data, configuration, and non-functional requirements, such as performance and logging, between tenants. This isolation creates challenges and introduces additional complexity into the application’s source code and database architecture.
  • Complexity: Unlike single-tenant applications, multi-tenant applications are more complex, mainly because you have multiple tenants, each with isolated data and configuration storage. When a multi-tenant application is shut down due to database unavailability, all tenants using the application are affected.
  • Security: Even though other tenants cannot access your data, your organization’s data is stored in a single database that is accessible to all users associated with your organization, which can lead to major security issues for tenants if the backend code is mishandled.

6. Multi-tenant application capabilities

These are the salient characteristics of a multi-tenant architecture:

  • Tenant data isolation: Tenant data isolation is one of the most important features of multi-tenant applications. This means that each tenant can only access its data. Data in a multi-tenant application is logically and physically isolated on a per-tenant basis, with one tenant unable to access data related to another tenant. You may have to configure a different application for each tenant. Such configuration data may typically include authentication keys, database connection strings, and so on.
  • Tenant resolution Policy: A tenant resolution policy indicates on which tenant context a particular request should be executed. Tenant solution policies should consider the databases that tenants can access, the configurations to use, and so on. In a multi-tenant application, you should formulate a tenant solution.

7. Multi-tenant database

A multi-tenant database is a shared database with a shared schema that stores data related to multiple tenants. To isolate data associated with different tenants, tenant identifier columns are commonly used. Multi-tenant applications follow one of the three database architectures discussed in the next section.

7.1 Types of multi-tenant Databases

You can use logical or physical isolation to implement multi-tenancy. Tenants should be logically isolated, but the degree to which they are physically isolated may vary. When implementing logical isolation for tenants, you should also be aware of two issues, such as data isolation and cross-tenant access. The former involves the need to isolate data for a particular tenant, while the latter implies access to data by users who are part of multiple tenants.

There are three types of approaches to designing a multi-tenant database, based on access to the data:

  • Multiple databases: Each tenant has only one database
  • Each tenant has a single database with a separate schema
  • A single database with a shared schema

7.1.1 Multiple Databases: One database for each tenant

Each tenant designs a database that provides the highest level of data security. Databases are physically separate, and one tenant cannot access data related to another tenant, so you can better isolate data as well. This approach is flexible enough that you can easily restore the tenant’s data if needed, but you must pay an additional server fee. In other words, you can isolate data better, but at the cost of increased complexity – complexity in administration, maintenance, and scalability, because you have to deploy multiple databases.

7.1.2 Each tenant has a single database with a separate architecture

In this model, one database is used, but there are multiple schemas: one per tenant. Each tenant has its own schema within the database, which typically consists of a set of tables. If you are willing to reduce the operating costs of the database layer and the complexity of the server infrastructure, you can choose this design. The downside of this approach, however, is that you need to spend more effort backing up and restoring data, especially if the data associated with a tenant has been corrupted.

7.1.3 Single database with shared schema

This is a simple design that is easy to implement. You have a shared architecture that all tenants use. Essentially, the architecture is the same for all tenants, that is, all tenants use the same database tables. You don’t need to create a schema for each tenant or run other servers for the database, and you often need to use a tenant ID to retrieve data related to a particular tenant. However, the downside is that over time, as more tenants use the application, it becomes more difficult to query or update the data.

7.2. Tenant Identification

Applications built with a multi-tenant architecture are good at responding differently to various customers or tenants. Multi-tenant applications can identify which tenant a particular request is coming from. In other words, tenant identification determines which tenant is involved based on available information, such as host name, source IP, or custom HTTP headers. Each tenant has a specific unique identity, and the behavior of the application is different from one tenant to another. Such changes may include UI changes, data changes containing configuration parameters, and behavior changes.

One tenant’s identity is different from another. The two tenants may differ in one or more of the following:

  • Data: Each tenant can access only its own data. Each tenant has its own configuration data, namely connection strings, workflows, domain names, and so on.
  • Behavior: One tenant may have different behavior from another depending on the functionality it accesses.
  • User interface: The look and feel may include style sheets, images, etc.

7.3. Multi-tenant Architecture: Challenges and Solutions

Possible challenges and solutions:

  • Security: Security is critical in multi-tenant applications. Protect applications and their data with the right security algorithms and the highest levels of security. Human error can compromise data security, and applications and databases can be accessed by unauthorized persons. There is also the threat of hackers; No matter how secure an encryption algorithm is, a clever hacker can compromise security. Develop appropriate security policy to solve this problem, of course, not only rely on one security algorithm. Some companies have certain regulatory restrictions that may prevent data from being stored in a shared infrastructure. In addition, corrupted data from one tenant can be disseminated to other tenants if the infrastructure is not configured correctly.
  • Performance: If one tenant is using too much computing power, it can adversely affect the performance of other tenants.
  • Loosely coupled: If you are using a single code base to satisfy multiple tenants, your application code should also be loosely coupled and configurable. You may want to decide whether you should have customer-specific source code branches or provide this flexibility in a single code base.
  • Complexity: Multi-tenant applications are much more complex than single-tenant applications. Database administrators need the right tools and knowledge to maximize capacity while reducing costs. To ensure that you are in compliance with service level agreements, delivery and availability must be properly monitored.
  • Tenant resolution Tenant resolution is a technique for matching requests to tenants. There are several ways to do this, but it’s not limited to this.
  • The host header
  • Request path
  • Request headers.

8, summary

Multi-tenant system is the foundation of building SAAS platform, so at the beginning of the design, should think about and weigh the advantages and disadvantages of various programs in this regard, combined with the resources of the company to choose their own programs, there is no need to mechanically copy, one step in place!