Several days ago I found this video: https://www.youtube.com/watch?v=fuDZq-EspNA
it is very AWS specific but generally provides some ideas.
Now regarding multitenancy, in general, there are couple options:
- separately launched apps with their resources
- I’ve seen people use PostgreSQL schemas or something to separate everyone in a single DB.
There can also be mixed solutions when you have pools of users in single apps, it is a mix of tenant_id based approach and separate apps. It is useful from an economic point of view. By putting multiple small projects to run on a single set of resources you optimize costs.
Same approach can be useful when you allow customers to select the region. You can have tenant_id based separation in NYC, SFO, Asia, Europe.
https://frontapp.com/ on their podcast said they use separate S3 buckets for every customer.
https://softwareengineeringdaily.com/2018/09/24/front-engineering-with-laurent-perrin/ Very insightful, I totally recommend to listen to this.
With https://appliku.com/ I use a tenant_id approach but only on main entities – application and servers. The rest of the data is tied to one of these objects anyway.
It all depends on the app, the usage pattern, amount of data stored, and processed.
in some cases, you just obligated to run each tenant separately by contract or regulation of some kind.
Also business model/pricing model dictates certain approach. If you make self-service solution for low cost of each tenant – you need to minimize costs of running the app.
If you have enterprise sales approach and have huge ARPU then at least you can afford having totally separate set of resources(read: run a separate instance of the app).
Keep in mind that managing fleet of separate apps is a whole different story from a single app with many tenants.
Hope this helps.