Some Patterns of Multi-Tenant SaaS
- There’s no one blueprint for SaaS architecture. Sure there’s patterns, but those are just tools for thinking.
- Metrics - capturing tenant context in metrics tends to be useful
- Compliance - SOC 2, HIPAA, GDPR etc. Depending on the countries and industries you serve, you have to be aware of any compliance requirements.
- Isolation - Compute, memory. This is when you start to think about the Noise neighbor & performance requirements.
- Storage Partitioning
- UI whitelabelling (doing an E2E PoC on this would be cool)
- When designed well, you shouldn’t have to think about multi-tenancy a whole lot when writing application code. This is preferred, as it greatly reduces Extraneous Cognitive Load
- Logging - similar to metrics, it’s important to capture tenant context here
- Onboarding: preferably automated. Whether it’s B2C (customer onboards themselves onto the platform), or B2B (internal team onboards customers), it’s good to have this process as frictionless as possible.
Silos vs Pools
Resource isolation is an important topic
- Silo is a fully isolated environment, services being run and hosted for one tenant only
- Pool is the other side of this, shared resources
- The choice of silo or pool can be done on a case by case basis
- Isolation can be achieved via siloed infrastracture, or through runtime policies
- Approaches to implementing multi-tenancy in SaaS applications
- Multi-Tenancy Trends in SaaS Applications
- Multi tenant Architecture for a SaaS Application on AWS
- Evolving the App to Multi Tenant
- DDG search
- Architectural approaches for compute in multitenant solutions
- this youtube playlist of mine has a bunch of reference resources for multi-tenant-architecture