Multi-Tenant SaaS Architecture

An architecture where a single instance of a software application serves multiple customers (tenants), each with logically isolated data and configuration, sharing the underlying infrastructure.

"Our multi-tenant SaaS serves 3,200 SMB tenants from a shared Kubernetes cluster. Tenant isolation is enforced at the application layer — each tenant's data is partitioned by a tenant_id column with row-level security policies."

A multi-tenancy isolation strategy where all tenants share the same database and infrastructure, separated only by application-layer logic. Offers the lowest per-tenant cost but the highest blast radius and compliance complexity.

"We use the pool model for our Starter and Growth tiers — all 3,000+ tenants share a single database cluster with row-level security. Enterprise customers requesting dedicated infrastructure move to the silo model."

A multi-tenancy strategy where each tenant receives a fully dedicated stack (dedicated database, compute, or even AWS account). Provides strong isolation and compliance but at higher cost and operational complexity.

"Our Enterprise tier uses the silo model — each tenant gets a dedicated RDS instance and their own VPC. This is required by SOC 2 Type II enterprise customers who need to audit their own database backups."

A hybrid multi-tenancy strategy that combines pool and silo patterns — smaller or lower-tier tenants share infrastructure while high-value or compliance-requiring tenants receive dedicated resources.

"The bridge model lets us serve 95% of tenants in the pool at low cost, while the 5% Enterprise tenants who need HIPAA BAAs or dedicated instances get silo deployment — paid at the Enterprise tier price point."

A multi-tenancy problem where one tenant's workload consumes a disproportionate share of shared resources (CPU, memory, DB connections, I/O), degrading performance for other tenants on the same infrastructure.

"We detected a noisy neighbour incident: one enterprise tenant's bulk export job was consuming 70% of the shared RDS read replica I/O. We moved them to a dedicated read replica and added per-tenant query rate limiting."

The set of mechanisms — data partitioning, access control, network policies, encryption — that ensure one tenant cannot access, affect, or inspect another tenant's data or resources.

"Tenant isolation is enforced at three layers: application (tenant_id checked on every query), infrastructure (namespace-level Kubernetes network policies), and data (column-level encryption with per-tenant keys)."

In SaaS architecture, the shared management layer responsible for tenant provisioning, billing, configuration, authentication, and operational management — distinct from the data plane where tenant workloads run.

"The control plane handles everything except customer data: tenant sign-up, subscription management, feature flag assignment, and usage metering. It runs in a dedicated AWS account with elevated audit logging."

The layer of a SaaS system where tenant workloads actually execute and tenant data is processed and stored — isolated from the control plane that manages the tenants.

"The data plane is where tenant application logic runs — in the pool model this is a shared cluster; in the silo model this is a per-tenant deployment. All data plane activity is scoped to a single tenant."

A service that determines what features, resources, or API capabilities a specific tenant is authorised to access based on their subscription tier, add-ons, and custom agreements.

"When a tenant tries to enable SSO, the API checks the entitlement service first. If their tier doesn't include SSO, the response is a 403 with a clear upgrade prompt rather than an unexplained error."

A subscription level that bundles a defined set of features, limits (seats, API calls, storage), performance SLAs, and support offerings. Tiers are the primary commercial dimension of a SaaS product.

"Our three tiers: Starter (pool, 5 users, 10GB, community support), Growth (pool, 50 users, 100GB, email support, SSO add-on available), Enterprise (silo, unlimited users, dedicated infrastructure, SLA, custom MSA)."

The automated sequence of provisioning steps executed when a new tenant is created: schema migration, default configuration injection, role and permission seeding, and optionally a new dedicated infrastructure stack.

"The onboarding pipeline runs in under 2 minutes for pool tenants: create tenant record → run schema migration → seed default roles → generate API key → send welcome email. Silo provisioning takes 8 minutes due to infrastructure spin-up."

A control that restricts a single tenant's API call rate or resource consumption to prevent them from monopolising shared infrastructure — a primary defence against the noisy-neighbour problem.

"We enforce per-tenant rate limiting at the API gateway: Starter is 100 req/min, Growth is 1,000 req/min, Enterprise is negotiated. When a Growth tenant hit the limit, they received a 429 with a Retry-After header rather than affecting other tenants."