Multi-Tenancy Architecture

The Apartment Building Analogy

Think of Single-Tenancy as a private villa. You own the land, the pipes, and the roof. It's secure, but expensive to maintain.

Multi-Tenancy is a luxury skyscraper. Tenants share the foundation, the elevators, and the utility lines (the code and infrastructure), but they have their own locked front doors and private living spaces (the data).

The Goal: The tenant should feel like they are in a private villa, oblivious to the 999 other people living in the same building.

1. The Three Models of Data Isolation

The most critical decision in multi-tenancy is how you store the data. There is always a trade-off between Isolation and Cost-Efficiency.

A. Database-per-Tenant (The "Silo" Model)

Each customer gets their own physical database instance.

• Pros: Maximum security, easy backups, no noisy neighbors.
• Cons: Nightmarish to scale; expensive. Imagine managing 1,000 separate Postgres clusters.

B. Schema-per-Tenant (The "Bridge" Model)

One database, but each tenant has their own private schema (namespace).

• Pros: Good balance; shared compute but separate tables.
• Cons: Difficult to migrate 1,000 schemas simultaneously during an update.

C. Shared Schema (The "Pool" Model)

Every tenant lives in the same table, separated only by a tenant_id column.

• Pros: Massive scale, lowest cost, easiest to manage.
• Cons: High risk of "Data Bleed" if a developer forgets a WHERE tenant_id = ? clause.

2. Visualizing the Multi-Tenant Request Lifecycle

A request must be "Context-Aware" from the moment it hits the Load Balancer until the database returns the result.

3. Solving the "Noisy Neighbor" Problem

In a shared environment, one "heavy" tenant can consume all the CPU/RAM, causing the system to lag for everyone else. This is the Noisy Neighbor Effect.

Strategic Mitigation:

1. Rate Limiting: Implementing Per-Tenant quotas at the API Gateway layer.
2. Resource Quotas: Using Kubernetes (K8s) namespaces to limit the "blast radius" of a single tenant's compute usage.
3. Tiered Infrastructure: Moving high-paying "Enterprise" tenants to dedicated workers while "Pro" tenants share a pool.

4. Engineering the "Great Wall" (RLS)

To prevent data leaks in a shared schema, I implement Row-Level Security (RLS) at the database level (e.g., in Postgres). This ensures that even if a developer writes a "bad" query, the database itself refuses to show data that doesn't belong to the active session's tenant_id.

-- The Database-level safety net
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation_policy ON orders
USING (tenant_id = current_setting('app.current_tenant'));