2

I would like to make a SaaS which would be a multitenant system. Development is done in Laravel, which is less important. What I would like to know is how would you handle having a master admin account (for me) with which I could observe number of tenants, subscriptions and their types, permissions and so on?

Currently I have a setup where each new tenant gets his own subdomain (so tenant t1 would be at t1.example.com).

Now what bothers me with routes and system integrity is that I have a table/model Users where a single user can belong to a single tenant, whereas a tenant have many users. In this setup it feels somewhat unnatural to have my admin account belong to no tenant as I believe that can bring more problems down the road.

Having a dummy tenant also crossed my mind, but I'm not sure this is a right path to go as well.

I was also thinking of having a split system which would be responsible for non-tenant specific stuff, so that on the one hand I could observe tenants and system-wise actions, while the other system would be tenant oriented so that it has all the necessary DB relations. I suppose in this setup I would have to have 2 separate User models so that one is not dependant on tenant. This feels like a lot of duplication though.

What are your experiences?

1 Answer 1

2

What I would like to know is how would you handle having a master admin account (for me) with which I could observe number of tenants, subscriptions and their types, permissions and so on?

You can have a separate domain admin.example.com. Also have a list of reserved subdomains which won't be allowed for tenants.

Now what bothers me with routes and system integrity is that I have a table/model Users where a single user can belong to a single tenant, whereas a tenant has many users. In this setup it feels somewhat unnatural to have my admin account belong to no tenant as I believe that can bring more problems down the road.

Your admin login would be separate than Users. Make a separate table say: admin_users. You need to design composite primary key for your Users table. When (id, tenant_id) would be your primary key. In order for the admin users, to login to tenant website - t1.example.com, insert all records from admin_users to Users table with respective tenant_id.

table: admin_users // This would work mainly for admin.example.com
id, name
121, Admin 
123, Norgul

table: users // This would work for tenant's users as well as you as an admin can "login as tenant" into tenant system for debugging or setup.
id, tenant_id, admin_user_id
1, 1,  121 // admin user
2, 1, 123 // admin user
3, 1, NULL // tenant's user

table:sub_domains
id, sub_domain, tenant_id
1, t1, 1

This way there would be a complete separation of your admin_users and tenant users. At some point, you would need to create 1 tenant's admin user who has permissions to create other users under his tenant_id.

Routes

Routes would be same for all subdomains, but depending on tenant_id, you would load that tenant's data. Whatever tenant specific tables your create, you would need to have (id,tenant_id) as a composite primary key.

Based on the URL, you would detect tenant_id from sub_domains table.

Scalable

In future, when the traffic and transactions increase, you could easily move the data for a particular tenant to a different database server. In your sub_domains table you would do the mapping of tenant and database.

Non-tenant specific things

There would be some tables like type tables, countries table, tenant_status, etc. which are not client-specific. You won't add tenant_id field in such tables. We call such tables as master tables.

Permissions Say your urls are like: t1.example.com/manage_users/add_user. Where manage_user is the module and add_user as action. You can have a permission middleware or just a permission layer, which would check the permissions table for the current user and current module. If permissioned, show the page else show error message.

Experience

This kind of multi-tenancy architecture is most successful. I am using a similar architecture and used it earlier too. We started with single database and two schemas: admin, tenants. Then we moved tenants to different databases. As tenants increased, we created more tenant databases. Refer: https://docs.microsoft.com/en-us/azure/sql-database/saas-tenancy-app-design-patterns

1
  • Of your three recent answers, this is the strongest. It provides a reasonable amount of detail and is backed with an external reference.
    – user53019
    Commented Sep 28, 2019 at 13:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.