🔗 Multi-Tenant Architecture

A discussion about the different strategies for a multi-tenant architecture.

You have 3 general strategies for this:

• Silo - app + db for each tenant is completely separated. Works great for SaaS when you have infrastructure as code e.g. you're using Terraform or something similar. The most expensive option and the most flexible as your tenants can possibly decide on the version of the app and other things. You will e> ither need a companion app for management or use something from a cloud provider.

• Bridge - app is shared, but each tenant has either their own DB or their own schema within a DB. You should automate at least schema creation and db migrations. Tenant's data is easily backed up, but all tenants (within a cluster anyway) should probably use the same version of the app - or you should have a> robust versioning strategy as far as DB changes go. You will probably need to build somekind of backoffice app for this (with its own db), or leverage whatever tools your cloud provider offers.

• Pool - app and DB are shared between tenants, and tables within a DB are partitioned by tenant. This is the least flexible option but the cheapest as you do not need much investment or have a good idea about infrastructure you'll be running the app on. Basically you add a table to the db with tenants and e> very table that has tenant data has a FK to this table - or at least the parent tables should. Children tables can omit tenant FK, but you should be then careful that they're only queried when joined to a parent.

There are of course variants and nuances, but that is the gist of it. To get the feel for this, I suggest you start with the last option, as it is simplest to understand and you need the least infrastructure for it (app + db).

continue reading on www.reddit.com

⚠️ This post links to an external website. ⚠️