When developing software that will be used by multiple tenants, it is crucial to choose the appropriate solution architecture and data structure. This is important from the perspective of both code development and data security.

Let’s consider a scenario where we are creating an application in the SaaS model which will be used by many companies. In such a situation, ensuring that any new features implemented are secure and effective for all customers is necessary. Creating separate instances of the application for each tenant is not advisable when there are many tenants, as it can lead to several issues, particularly during the installation and maintenance process.

In this case, a multi-tenant architecture is the ideal solution.

What is a multi-tenant architecture?

This term refers to an application that supports multiple tenants within a single instance. It is crucial to maintain separation between the data of different organisations while making the program appear as an independent instance.

By a tenant, we usually mean a company that uses the software to provide resources to its employees or customers. Examples of such applications include process or project management tools, CRM systems, ticketing platforms, etc.

In the case of a single-tenant architecture, an organisation has its infrastructure and a separate instance of the program. This method is manageable for a few instances, but as the number of tenants increases, managing individual instances and deploying new versions becomes more challenging and time-consuming. Additionally, infrastructure maintenance costs increase. This approach is suitable for on-premise distribution, but SaaS solutions benefit more from the “multi-tenant” approach.

Database Strategies

Selecting the appropriate database architecture is crucial. This decision is vital in ensuring data security, application scalability, and the ability to develop and publish securely.

The following possible solutions are presented along with a detailed analysis of their advantages and disadvantages.

Single Database

In this scenario, all customer data is stored in a single database, with each table having a column that defines a specific tenant, such as tenant_id. This is a widespread solution because of its straightforward architecture.

However, this approach has several crucial drawbacks from the perspectives of security and scalability.

To access data from a particular tenant, each query to the database must contain a condition (WHERE) that specifies the tenant id. This poses a significant security risk. In case of a bug in the code, missing such a condition could lead to the exposure of customer data to unauthorised parties.

Moreover, this model limits the possibility of scaling the database to more servers. It is also complicated to export the data of a particular tenant, for example, when switching to an on-premise service.

Multiple databases

An alternative strategy for managing customer data is to create a separate database for each tenant. This approach offers several benefits and addresses most of the issues that arise in a single database scenario.

Firstly, this architecture ensures complete separation of customer data, eliminating the need to add conditions to queries for each tenant. This reduces the risk of data leakage between accounts.

Moreover, such an infrastructure provides greater scalability possibilities. Separating customer data into separate databases makes it easier to use more servers and significantly improves performance in the long run. It also simplifies the process of exporting customer data and creating backups.

However, implementing this approach requires a more complex process of updating the database structure and publishing new versions of the application. Nevertheless, considering the higher level of security and infrastructure possibilities, this architecture is often the better design decision.

User Files

It is important to remember that user data may not only be stored in the database but also in files. The best approach is to create separate directories for each tenant. This approach provides greater flexibility in management, such as backup, deletion, and relocation.

Regardless of your file storage strategy, it is essential to remember that users’ files should not be directly accessible from the browser. Such data should be stored outside the ‘document root’ directory, and access should only be granted through the application logic.

Domain Strategies

In a multi-tenant architecture, choosing a domain strategy is essential. Each available solution differs in possibilities from the tenants’ perspective and affects the implementation approach.

Subdomains

A convenient and flexible scenario is to provide each tenant with a separate subdomain. This way, the application is available for each customer at a different, unique URL. This gives you many customisation options, e.g. for the appearance. This approach allows users to log in to different accounts on different subdomains.

This configuration can be applied to a single database as well as to separate databases for individual tenants.

Separate domains

An alternative way is to use separate domains for each customer. This is especially important if a given tenant wants to use the application under their brand (white label), then their domain is attached.

This configuration works best with a solution with separate databases.

A common scenario is to use both of the above strategies simultaneously – i.e. for a higher type of account, an option with its domain is available, and for lower subscriptions, an application subdomain is provided.

Single Domain

Another option is to use a single domain for all customers. In this case, individual tenants don’t have unique URLs. Users don’t have to think about the login address (they don’t need to know the dedicated subdomain/domain), but this limits the possibilities of personalising the appearance and operation under their own brand.

In this scenario, there is also the issue of handling cases where one user needs to be assigned to multiple tenants using the same email address as a login.

A single database solution is most commonly used for this type of configuration.

Summary

Regarding software that serves multiple tenants, making the right design decisions for the entire solution is crucial. This is vital for ensuring functionality, user experience, and data security. Adequate project preparation can also streamline future development and maintenance.

---