Single tenant vs multitenancy – choosing the optimal solution.

What is Tenancy?

Tenancy, what truly is it for? There is often a business need that involves using ecosystems by multiple organisations/clients and each of them wants their data to be separate from each other. You can achieve this with tenancy. You can do it with either single tenant deployment (setup per organisation) or with a multi-tenant setup (multitenancy). Using the proper tenancy model can either solve or introduce issues such as unwanted data modifications, data leaks, ease of branding and much more. Choosing the correct tenancy implementation from the start is the key to system maintenance and on pace development.

Common security threats while using the tenancy

Accidental data modifications

Unintentional changes to data can happen when party A (a genuine representative of tenant A or a system account) mistakenly performs CRUD-like actions on party B’s data, believing it to be their own. While this can be caused by multiple reasons, the outcome is the same – party B’s data is exploited, which makes the whole system unsafe. It is a hard-to-recover situation, not only to fix the data – but there is also the risk of a big reputation loss, which can follow the company for many years, impacting the client’s base and income.

Data leaks and their impact

Data leaks can happen for both internal or external reasons, inc. hacking and business intelligence. Both can be minimised by having tenant atomic rights in the system. 

Let’s imagine a scenario where the system representative account of party A gets hacked. The endangered data would only pertain to the tenants of this representative. No other party is affected, resulting in more limited implications regarding business responsibility (time, money, and reputation).

Single tenant vs multitenancy – the differences

Two paths we can follow when it comes to tenancy execution.

Single tenant

The concept of ’setup per tenant’ involves creating full deployments for a given tenant. This ensures its isolation at the infrastructure level with a dedicated frontend, backend, and domain.  No additional logic flows within the application, resulting in almost identical (though traffic-dependent) setups at the infrastructure level. However, this significantly increases resource usage, SRE/DevOps support requirements (time, cost, team size), and application maintenance during deployments – each setup needs to be migrated individually to the newest versions.

The primary advantage of using physical multitenancy is its near-unbreakable isolation. This allows for atomically managing the support team’s access and enabling releases on different schedules due to the full tenant separation. Additionally, this approach makes branding and code customizations simple and fast.

Multitenancy

The multi-tenant approach uses the same setup for all tenants while ensuring isolation through additional flows glued into the application code. Security in this solution is based on the quality of the glueing code itself – which should be designed and implemented to be bulletproof and hassle-free to use. This approach offers better scalability, optimised resource utilisation, as well as ease of deployment and SRE operations, leading to significant time and cost savings in the long term, but requiring more time and resources at the beginning.

In the best implementation scenario, multitenancy should be treated as a first-class citizen right from the start of the project. It can be unwrapped with other headers in the Gateway and then passed to Services for implicit reuse. By ‘implicit reuse’, we mean that tenancy is not directly used in the majority of the high-level code (e.g., business logic), but instead, it is utilised through highly reusable and transparent facades in the low-level code (e.g., repositories using well-structured DAO base implementations, not just simple WHERE clauses).

It’s worth mentioning that the branding process in this setup requires more work on the Backend/Frontend to serve assets based on the specific tenant.

Single tenant vs multitenancy – which is better?

There is no one universal answer to such a question. Single tenants can be appealing not only for big-scale companies handling hundreds of clients but also for startups, as it is the easiest and most secure option for the start. However, maintaining all of the clients and ensuring constant uptime of the anchored nodes for a given tenant can become challenging and costly. 

On the other hand, multitenancy separation can reuse existing resources to reduce costs but requires better integration into the heart of the given ecosystem – preferably from the beginning to ensure optimal ease of implementation.

An important variable that needs to be considered when thinking about the tenancy model is (API) Gateway/IDP Provider (auto)scaling and support. While it may not be an issue for a few tenants, it can become vulnerable as the number of users, tenants, or data increases. The solution’s resilience depends on the specific tools being utilised, so it’s essential to double-check this factor using official documentation and community resources.

Key factor’s summary for single tenant and multitenancy

Single tenant vs multitenancy – conclusion

If you assume to serve multiple clients and your model is SaaS, then multitenancy might be the best choice for you as it is more beneficial to make an initial investment in the design than to pay for adjusting an already running system later while supporting and updating all of the existing and new tenants on a separate basis.

Single tenancy is quite an easy concept to grasp. Multitenancy is more complicated – and we will be providing you with a detailed business overview of it in the next article.

If you don’t want to miss it, be sure to subsribe to our newsletter!