Some Patterns of Multi-Tenant SaaS

Disclaimer

  • There’s no one blueprint for SaaS architecture. Sure there’s patterns, but those are just tools for thinking.

Management

  • Metrics - capturing tenant context in metrics tends to be useful
  • Analytics
  • Billing
  • Provisioning
  • Compliance - SOC 2, HIPAA, GDPR etc. Depending on the countries and industries you serve, you have to be aware of any compliance requirements.
  • PII

Application

  • Isolation - Compute, memory. This is when you start to think about the Noise neighbor & performance requirements.
  • Storage Partitioning
  • Deployment
  • Routing
  • 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

Tenancy

  • Identity
  • 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.
  • Tiering

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

Reading list