Open shailee-m opened 5 years ago
Approaches to multitenancy:
1) Separate database for each tenant:
There will be a tenant manager collection which enlists all tenants of the platform. Each tenant will have a separate database created when the tenant is registered. The users collection can either be separate for each db or if a user can be a member to multiple tenants there can be a shared collection.
Pros:
Cons:
2) Having a common database for all tenants.
There will be only one database having a tenant collection, in addition to the exisiting collections. Each of the existing collection will have and extra key called the tenantID which distinguished the data tenantwise.
Pros:
Cons:
For user login and registration:
Have a base url where the tenants can register their organisations. From then on they can login/regsiter new users on a subdomain url. (Example, The tenant google will register itself at gerilife.com, where as users of tenant google will register/ login at google.gerlilife.com).
No separation of tenant by domain. While registering the user sets a domain. Then for tenant distinction during login, the following methods can be used:
In a url domain based approach there will not be major changes to the existing login module whereas using the second approach the login and registration modules will require refactoring.
Additional points: Can introduce a tenantManager user role whose role is limited to managing the tenancies.
@brylie
Thanks @shailee-m. We will discuss these options.
Considerations
This should be compatible with our Mobile Client task #546