Choosing between single tenant and multitenancy

Single tenant vs multitenancy – choosing the optimal solution.

Choosing between single tenant and multitenancy

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

Using 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

Factor Single tenant Multitenancy
Time spent on Initial development Standard A larger time investment is required (it will pay off in the future)
DevOps/SRE support Higher level of support required – goes up with new tenants Less than single tenancy (resource reuse) usually allows achievement of the desired results by adding new nodes horizontally.
Branding/Customisation Standard Slightly higher – requires tweaks to handle assets depending on the tenant.
Long term development Standard for cases where all tenants use the same code, higher when tenants are customized. Standard for cases where all tenants use the same code or are based on the same feature toggle system. High where tenant customizations are needed in the logic.
Deployments Much higher, goes up with new tenants to the point of pain Standard, usually horizontal scaling is enough for maintaining the system’s health and functionality.

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!

Download e-book:

Scalac Case Study Book

Download now

Authors

Arkadiusz Kaczyński
Arkadiusz Kaczyński

Scala Developer

Latest Blogposts

07.06.2024 / By  Arkadiusz Kaczyński

Single tenant vs multitenancy – choosing the optimal solution.

Choosing between single tenant and multitenancy

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 […]

06.06.2024 / By  Michał Talaśka

Java outsourcing projects: how to ensure security and compliance.

Java Outsourcing Development

In today’s world, security and compliance are paramount. A day without news of a data breach is quite rare. When it comes to outsourcing Java projects – one of our specialties – safety should be a priority. With the growing complexity and sophistication of cyber threats, businesses need to make sure that their Java outsourcing […]

30.05.2024 / By  Matylda Kamińska

Scalendar June 2024

Scalendar Scala conferences 2024

Event-driven Newsletter Welcome to June Scalendar! Join us in exploring conferences, meetups, and gatherings that promise to enrich your knowledge, expand your professional network, and inspire your career path. From Tokyo to Atlanta, Vienna to Rome, experts and enthusiasts from the global tech community come together to share knowledge, experiences and – last but not […]

software product development

Need a successful project?

Estimate project