Multitenancy
Multitenancy is an architectural pattern where a single instance of a software application serves multiple customers (tenants). Each tenant's data is isolated and remains invisible to other tenants, even though they all use the same application and infrastructure.
SuperTokens core provides a three level hierarchy for the multi-tenant system:
- Connection URI Domain (CUD)
- Apps
- Tenants
Connection URI Domain (CUD)
This is the domain name that's used to connect to the core instance. We can create an effective multi-tenant system by pointing several different domain names to the same instance of core and they will operate as if they were separate cores.
Note: It is mandatory that each of the CUD must connect to it's own database and the connection details must be specified while creating it.
A new CUD can be created by calling this API: PUT /recipe/multitenancy/connectionuridomain/v2
App
This is the next level of hierarchy. Apps are hosted within each of the CUDs. It is not mandatory but possible to allocate separate databases for each of the apps.
Tenant
This is the final level in the hierarchy. Again, each of the tenant within the app can share the database or use separate databases.
Tenant List
Core always maintains list of all tenants, identified by (CUD, AppId and TenantId) in memory. The list is always synchronised with the database to ensure any changes are propagated to the memory.
supertokens_saas_load_only_cud config
When this config is set in the config.yaml, the core would only load the CUD specified in this configuration. All the other CUD and their respective apps and tenants will not be accessable from this instance of core. This can be useful if the same infra is hosting a lot of CUDs and you wish to add separate instance of core for specific CUDs.
Classes
MultitenancyHelper an extension of Resource Distributor provides the necessary functionality to manage the list of all tenants in the core.