Free — no signup required

Introduction: The Noisy Neighbor Problem

2 min read

What Is a Tenant?

In software, a tenant is a customer or organization using your platform. When you build a SaaS product, you must decide how to share — or not share — your infrastructure between tenants. This decision has profound consequences for security, reliability, cost, and operational complexity.

Think of it like an apartment building. You can build one giant open-plan floor where everyone shares a kitchen and bathrooms (efficient, cheap, but one person's mess affects everyone). Or you can build individual apartments with their own kitchens and bathrooms (more expensive to build, but completely isolated). The "noisy neighbor" problem is what happens when one tenant's behavior — a traffic spike, a runaway query, a memory leak — degrades the experience for every other tenant sharing the same resources.

The Two Ends of the Spectrum

When building SaaS, you have two fundamental approaches to tenant isolation:

  1. Pool Model (Shared): All tenants share the same infrastructure — one database cluster, one fleet of application servers, one Kubernetes namespace. Resources are allocated dynamically. This is efficient and cheap to operate, but tenants can interfere with each other.
  2. Silo Model (Isolated): Each tenant gets their own dedicated infrastructure — their own VPC, their own database, their own compute. Tenant A's database crash has zero effect on Tenant B. This is more expensive but provides hard isolation guarantees.

In practice, most production SaaS systems live somewhere between these extremes, and the right answer depends on your customer profile, compliance requirements, and scale.

Why Cell-Based Architecture Matters for IaC

The silo model is often called cell-based architecture — each tenant lives in their own "cell" of infrastructure. The challenge is: how do you manage 500 separate VPCs, 500 separate databases, and 500 separate IAM configurations without going insane? This is where Infrastructure as Code becomes essential — and where the choice of tenancy model in your IaC directly determines whether your platform scales gracefully or collapses under its own weight.

The three strategies below represent the main patterns teams use in Terraform to implement tenancy models, each with distinct trade-offs in blast radius, operational complexity, and state management.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free