Multi-tenant SaaS architecture: designing systems that survive growth

What is multi-tenant SaaS architecture?

Multi-tenant SaaS architecture is the design of a software product that serves many customers (tenants) from one operating platform, with each tenant isolated in data and experience even when infrastructure is shared. The core question is not whether to share, but which components to share, which to isolate, and by what mechanism. That choice drives cost, security, performance and delivery speed as the customer base grows.

At small scale the question is whether the product works. With growth it becomes: can the system serve the thousandth customer without slowing the first, and can someone who did not write it change it safely? This guide walks through the most important architectural decisions, based on the AWS Well-Architected SaaS Lens and the Azure Architecture Center's multitenancy guidance.

The three multi-tenant models: silo, pool and bridge

The AWS SaaS Lens groups SaaS architecture patterns into three categories. Silo is where tenants get dedicated resources, for example a fully independent infrastructure stack or a separate database per tenant. Importantly, a silo still relies on shared identity, onboarding and operations, which distinguishes SaaS from a managed-service model where each customer runs a separate version. Pool is where tenants share resources, the classic notion of multi-tenancy aimed at economies of scale and agility. Bridge acknowledges that systems are usually mixed: some parts silo, some pool. A service's data regulation profile and noisy-neighbour sensitivity might push it to silo, while the agility, access patterns and cost profile of another push it to pool.

The Azure Architecture Center describes the same spectrum: from a single-tenant deployment per customer (strong isolation but low cost efficiency because nothing is shared) to fully multitenant deployments, with horizontal partitioning in between, such as a shared application tier with a database per tenant. Azure also recommends the Deployment Stamps pattern, where a stamp can serve a group of tenants or a single tenant.

Tenant isolation and data partitioning

Tenant isolation means one tenant cannot reach another tenant's data or resources, even when code has bugs. Azure's multitenancy checklist recommends mapping every request correctly to a tenant, carrying tenant context in the identity system or application-level authorization, designing for isolation and continuously testing the isolation model.

In a pooled model with shared tables, the biggest risk is a query that forgets to filter by tenant. One defence is to push the boundary into the database: PostgreSQL Row-Level Security, once enabled on a table, requires every normal access to be allowed by a policy, and denies by default if no policy exists. The PostgreSQL documentation also notes that the table owner is typically not subject to these policies, so the application should not connect as the owner.

Noisy neighbours: when one tenant slows everyone

According to the Azure Architecture Center, the noisy neighbour problem occurs when one tenant's performance is degraded by another tenant's activity. It can also happen when each tenant uses only a small share but the combined load of many tenants with similar patterns produces a peak beyond capacity. Sharing a resource inherently carries this risk; it cannot be eliminated, only reduced and controlled.

• Monitor resource use per tenant, not just system-wide; include the tenant ID in telemetry.
• Apply resource governance: quotas, API limits, and the Throttling or Rate Limiting patterns.
• Alert on usage spikes and scale automatically where possible.
• Move heavy or sensitive tenants to their own stamp (silo) in a bridge model.
• Test to confirm that data does not leak between tenants and that noisy-neighbour effects are acceptable.

Scaling and observability

Azure recommends designing for the growth you expect without over-engineering for unrealistic growth, defining SLOs based on tenant requirements, and testing that the solution scales as tenant numbers rise. With shared compute, scaling benefits every tenant, but when capacity is insufficient all tenants suffer; dedicated resources scale independently but cost more.

For observability, monitor both overall health and each tenant, and configure and test alerts for when a tenant has problems or exceeds limits. Separate the control plane (onboarding, configuration, billing) from the data plane (serving requests), and automate the tenant life cycle rather than doing it by hand. Azure lists antipatterns to avoid: running separate versions per tenant, hard-coding tenant-specific configuration and relying on manual deployments. Infrastructure cost at scale also needs regular review (see cloud cost optimization).

Per-tenant metering and billing

Azure gives two reasons to measure each tenant's consumption: knowing the real cost to serve each tenant to track profitability, and determining what to charge under consumption-based pricing. The difficulty is that most shared services do not break usage down by tenant, for example one relational database holding every tenant's data.

Principles from Azure's guidance:

• Decide the goal first: an approximate cost to serve (enough for flat pricing) or precise measurement (needed for usage-based pricing).
• Do not use application monitoring tools as the billing data source, because they typically sample; build a dedicated, accurate logging pipeline.
• Real-time measurement is rarely needed: log the data and aggregate asynchronously.
• Avoid more precision than you need; it adds complexity and brittle processes.
• Pricing models (per user, consumption, flat rate) feed back into architecture: flat rate is easy to sell but can become unprofitable with heavy tenants; consumption pricing needs accurate metering and auditable records.

Record architecture decisions with ADRs

Many SaaS systems struggle not because of traffic but because nobody remembers why they were built that way. An Architecture Decision Record (ADR) is a short document that captures one architecture decision. Michael Nygard proposed the format in 2011 with Title, Context, Decision, Status and Consequences; ADRs are numbered sequentially, numbers are never reused, and when a decision changes the old ADR is kept and marked superseded. Martin Fowler stresses keeping ADRs brief, typically about a page, and notes that writing them clarifies a group's thinking.

A suggested ADR template for a tenancy decision (kept in the repository, for example docs/adr/0007-tenancy-model.md):

• Title: ADR 0007 – Pool model for the standard plan, silo for customers with specific requirements.
• Status: Proposed / Accepted / Superseded by ADR-xxxx.
• Context: current and expected tenant count, data regulation requirements, load patterns, team capability, budget constraints.
• Decision: “We will…”, in active voice, naming the isolation mechanism (for example Row-Level Security) and the criteria for moving a tenant to silo.
• Consequences: what becomes easier, what becomes harder, accepted risks and the follow-up decisions required.

Migration paths

Few teams pick the right model on day one, and changing the tenancy model is expensive because each tenant's data must move while they keep using the product. Azure notes that if you allow migration between deployments, you must plan how to move customers from a multitenant deployment to their own, and always know which tenants are where. Common paths:

• Single-tenant installs to SaaS: unify identity, onboarding and operations first, then consolidate infrastructure.
• Pool to bridge: move large or special-requirement tenants to their own stamp or database; requires per-tenant data migration tooling and a tenant-to-location catalogue.
• Monolith to separate services: gradually extract parts with different isolation or scaling needs and choose silo or pool per service.
• Give every migration step an ADR, an isolation test plan and a rollback plan.

How EYC can help

EYC builds Early Years Circle, a connected platform for early childhood education, and applies the principles in this guide when designing software. EYC's Software and SaaS practice can work with you to review your architecture, choose a tenancy model, set up an ADR practice and plan migrations; scope and commitments are defined under contract. Contact EYC to discuss.