Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers.
But then you might be wondering, "Don't all apps do this? What makes this so special?"
The answer to this lies in the fact that multi-tenant applications allow you to serve multiple customers with one install of the application. Each customer has their data completely isolated in such an architecture. Each customer is called a tenant.
Tenants may be given the ability to customize some parts of the application, such as the color of the user interface (UI) or business rules, but they cannot customize the application's code.
There are various approaches to multi-tenancy. Key among them are:
- Shared database with a shared schema.
- Shared database with isolated schemas.
- Isolated database with an isolated schema.
- Completely isolated tenants.
In this method, a single database instance keeps the tenant's records. As opposed to linking every tenant's data by a foreign key, as we would normally do, this is common in method 1 indicated previously
Shared database with a shared schema,
we create a new schema for every new tenant.
Multi-tenant applications are especially useful when it comes to building Software As A Service(SAAS) products.
Using this approach instead of single-tenancy, a number of advantages present themselves. Key among them:
- Affordable cost: Having multiple customers means that the cost of the environment(hosting, databases, and dev time) is shared. Those savings in turn are typically transferred to the cost of the Software.
- Adding a new customer is easier: in single-tenant apps, a fresh installation of the app is required every time a new customer comes on to the platform. With multi-tenancy, it happens in a matter of seconds using an API call.
- Convenience in maintaining a single application: As mentioned above, using the single-tenant approach means having multiple instances of the same application. You can imagine the nightmare of maintaining and updating all those instances as your customers grow. Good problems to have of course since you are obviously doing something right 😄, but nonetheless, it will result in a lot of time and resource wastage.
We'll be working towards building a multi-organizational expense tracker. The live demo can be found here.
The backend code is written in python(django) and deployed using docker-compose.
The repo has multiple branches representing the application at various stages. We'll move step by step to avoid information overload.
The frontend was built with vue.js, specifically nuxt.js, and deployed using pm2
In the coming posts, we'll get hands-on by building the functional full-stack application. By the end of the series, hopefully, you should be able to build similar systems.