The meaning of tenant in the Cambridge dictionary is a person who pays rent for the use of land or a building. But in multitenant systems, the tenant means a customer.
In short, a system is multitenant if it can serve multiple customers. A single instance of an application that can serve any number of customers. That's great, right?
Earlier companies used to create a new isolated instance for each new customer. This is fine but with each new customer addition, there is a lot of management involved. From codebase to deployments, handling everything for all the customers can get painful and the cost increases.
With a multitenant application, you can save on a lot of resources, your memory, CPU, can have a single database, a single codebase to maintain, and all of this serving multiple customers.
But wait, this can become a challenge too. Having a shared instance for multiple customers may cause security issues. If for some reason, one customer sees another customer's data or if the cache gets leaked to the wrong customer, you may get into big trouble.
So it's very important to write a good multitenant application with a good simulation of isolation at the application level.
Give me an example
Let's take Slack.
At first, Slack asks you to create a new workspace (which means you are creating a new tenant).
Once you create a workspace, you can invite and add members, you can create channels in your workspace, etc. These members, channels, threads, and all that you create in this workspace will not be available in any other workspace (of course).
Does Slack create a new database just for you? No! Your data is living with other customers' data in Slack's database in a secure way.
When you log in to the web version of Slack (as per December 2020), Slack will redirect you to app.slack.com/client/<client-id>/<conversation-id>.
Navigate to any other conversation (channel or a DM), and the conversation-id will change in the URL.
If you have any other workspace, log in to that workspace and check the URL. There will be a new client-id.
This is how even after you refresh, Slack will have the context of which workspace is currently being used. Try and change the client-id in the URL directly and it will redirect you to the sign-in-to-your-workspace page.
(These are my observations with the app, I may be wrong. Cut me some SLACK! 😜)
The Apartment Building Analogy
A building will have multiple apartments where they share the pipeline, the electricity line, the elevator, etc. Each tenant may invite guests to their apartment. All the tenants have customized their houses from inside. Some of the amenities are shared between all e.g. the pool, the gym.
So the building is our application, we just create one. Each of the apartments is like a tenant or the workspace. New members can be added to the workspace. Workspace can be customized as per the customer.
Database architectures that you can use
The first one is a multi-database architecture where we can spin up a new database for each customer. This architecture will give us the benefit of isolation but the management costs go up.
The next one is where we can use one database but multiple schemas. A database contains one or more schemas, which in turn contain tables. Schemas allow the database to be separated into logical groups. Each tenant can have one schema and all the tables required can be inside this schema. Once a new tenant comes in, a new schema can be added for this new tenant, and all the tables can be added to this schema as well.
The last one is the simplest, with only one database. We will have a table for storing the tenants in our system. Each tenant will have a record in this table. Every other table in the database will have a foreign key to the Tenant table. This is how we logically separate the data as per the tenants.
This was my attempt to give you a brief introduction to multitenancy.
In part II, we will build the backend for a multitenant application based on this architecture using the Django REST Framework.
Thanks for reading!
