When we decide to design software architecture for SaaS-based products, we might want to answer the question if we want our architecture to be a single-tenancy based or multi-tenancy bases. I can across this decision in one of the design docs I recently came across and thought of writing about it. I was also new to these concepts and had to do some homework to know more about them. So the fundamental difference between the two is that in a single-tenancy model, we have a separate instance for each tenant (or for the time we may call a client/customer) while for the multi-tenancy model, we use the same instance for multiple users.
To explain things better, let us take an example of a single-tenancy model. Such a model will have a separate database per customer, and a separate instance for each customer. The underlying code should not be very different for each customer as we would want the same piece of code to serve each of our customers. We would instead make sure that the data is separate for each customer and the tenant can, post adopting our software, customize it to its need as much as possible as long as the basic code behaviour is not impacted. For example, let's assume I am creating software for job applications for a company. The users can come to the software and apply to a company which is our customer/tenant. Now, we offer this software to say five different companies with the same basic code that allows users to create, submit and view applications for jobs. If we use a single-tenancy model, we would create a separate database for each company and we would be running separate instances for each company but the underlying code will remain the same. The companies are free to customize the software for what type of application they want to be submitted (subject to code constraints), the background of the software and UI/UX (subject to code constraints). Their data is separate and accessible. This model offers some nice perks like :
- Separate data reduces the blast radius if there is an attack on the data of one tenant.
- Customizable software with tenant satisfaction as he/she can customize a lot.
- Increased availability of to the tenant as resources are not shared.
But at the same time, this model comes up with some not so loved traits (and that's why they are used lesser than the multi-tenancy model) :
- Cost: Running separate instances and data stores per tenant is a costly affair and resources need to be allocated very wisely else we might end up wasting resources.
- Initial setup: When the tenant buys the software, he/she can't usually start using the software straight out of the shelf and has to do all the customizations based on the documentation and manuals and then train his/her users on that. It takes time and effort.
- Maintainance: Maintaining an instance per tenant is not an easy task as the number of tenants increase and beyond a point might get really messy and costly.
Despite all these, single-tenancy models are still used at places where the security of data and custom UI/UX is very important and where potential clients are not in huge numbers (for example, token systems in banks. Here data is critical, and we will most likely never have more than a few hundred banks operating the software).
Multi-tenancy is just the opposite of the single-tenancy model where we have a single instance and data source serving multiple clients. The pros and cons of using this model are just the reverses of the single-tenancy model. But eventually, the number of customers factor and cost of maintenance factor overshadows the security risk aspect at times and this model is more often used. One might as well invest in converting its "critical" or "red" data to "highly confidential" or "orange" data than separating the data to reduce the blast radius. Still, we do at times come across cases where both these models have a role to play. Knowing about them may help them come up with the best design document.
Found these links for reference helpful :
Amrit Raj
Comments