First, we must keep in mind that the SaaS application architecture must support multi-tenant from beginning, otherwise we will struggle with scaling the application in the future.
Application architecture level
- We must consider careful which is needed to separate: application, database, or what other else? It should use the same application level (source code) to be sure the system is easier to be maintained.
- For web application, each Tenant must have their ability to customize some elements such as look and feel (theme, layout organization such as menu bar, header, footer, etc.), language, uploaded content, and also add-on / customized features.
- Should have maintained page for each website so that when upgrading system for a large scale of tenant, we have enough time for it.
- Some concepts needed to be considered when adding custom logic: Modular, Hooks, Dependency Injection, Aspect-oriented Programming.
- When scaling, we normally do horizontal scaling (adding machines / nodes).
Database level
- We need to aware that we have 3 approaches for database approaching:
- Shared database, shared schema: define Tenant_ID per row
- Shared database, separated schema: 1 Schema per 1 Ternant
- Separated database: 1 DB per 1 Tenant
- When choosing one approach, we must consider if the isolation / optimization level is necessary. Be careful when using shared db and separated schema excepts you can accept a little number of tenants (such as multi-site in wordpress).
- For SaaS apps, we can separate paid and free customers into different approach:
- At the beginning (free tenant), we allocate the tenant to shared db + shared schema model to save cost. When scaling, we need to scale the whole db/schema. Be careful to choose tenant_ID since most of the case, incrementing id is not good for partitioning / sharding –> Should choose random tenant_ID.
- For premium/highly isolated tenants (CRM, cart, high load system which require different specific indexes, etc.), we should separate database to be able to flexible assign tenant to proper node. It is flexible to target tenant based on their budget / grow / resource consumption. Be aware that each db will need minimum resources so be careful when deciding the number of tenant per db node.
- Should rare to use shared db and separated schema since it is difficult to scale / cluster / shared. E.g. do not use each collection per tenant in MongoDB since it cannot be scaled well.
- We normally do vertically scaling (adding more resources to current machine) when scaling a shared multi-tenant database.
- If using separated db, we can easily scale the system by adding resources / replica -> horizontally scaling.
