Have you ever wondered about the sub-domain?
What is Multi-Tenancy?
Paying tenants is the most fruitful word in terms of finances for every landlord. All landlords have is an apartment, with each block apart that is being rented out. All the tenants inside the apartment are independent of each other.
Like an apartment, the Multi-Tenancy is a single instance of the programme and its accompanying infrastructure may accommodate many clients.
Multi-Tenant: The Definition
An example of a software design that allows for tenant isolation while allowing them to use the same infrastructure, database, or computer resources is the multi-tenant architecture. Despite using the same software, the tenants are completely anonymous, have no access to one another's data, and maintain complete confidentiality regarding their data. Almost every modern cloud-based platform is based on this architecture.
Examples: Hashnode, Github, Hubspot and many!
Multi-Tenancy: The Features
Several excellent and frequently necessary benefits are offered by a multitenant architecture:
Everything Everywhere all at once.
It enables the application to serve several consumers at once while sharing the underlying infrastructure and services.
L'échelle
The multi-tenancy model's strength is its capacity to scale. It's simpler to extend an app, add features, or delete features, and properly manage resources when compared to the single-tenant model.
Customer Customization = Customer Acquisition
Apps can be modified by tenants to suit their needs.
The Maintainance
The vendor makes changes concurrently for all tenants, such as switching to a different technology stack, addressing defects, performing planned upgrades, and releasing new product versions, there shouldn't be any problems with multi-tenancy. In addition, tenants benefit from the convenience of not having to manually download and configure upgrades.
The Schema schemes.
We have various ways to structure our schema in Multi-Tenancy.
Shared database with shared schema
Each tenant's data is stored in a distinct database. The tenant is identified by a ForeignKey in the tables.
Shared database with isolated schema
Each tenant's data is stored in a single database. The same database has distinct schemas for the data belonging to each tenant. The tenant is identified by the schema, however, the data tables lack an FK to the tenancy.
Isolated database with a shared app server
Every tenant’s data is in a separate database. The database identifies the tenant.