1. Multi-Tenancy | Engineering Notes

🧠 Multi-Tenancy (System Design Approach)

Multi-tenancy is how I design systems where multiple customers share the same application, while keeping their data:

isolated

secure

scalable

Each customer (tenant) should feel like they are using their own system, even though infrastructure is shared.

🎯 Why It Matters

In SaaS products, a single system often serves:

multiple companies

multiple organizations

multiple clients

If multi-tenancy is not designed properly:

data leakage can happen

access control becomes error-prone

scaling becomes difficult

So I treat tenant isolation as a first-class concern, not an afterthought.

🏗️ How I Think About Multi-Tenancy Models

There are three common approaches:

1. Shared Database, Shared Tables

All tenants share the same tables

Data is separated using tenant_id

Tradeoff:

simple and cost-efficient

but risky if tenant filtering is missed

2. Shared Database, Separate Tables

Each tenant has its own tables

Tradeoff:

better isolation

but more complex schema management

3. Separate Database per Tenant

Each tenant has its own database

Tradeoff:

strongest isolation

but higher cost and operational overhead

🔐 Data Isolation (Critical Thinking)

The most important rule I follow:

> every query must respect tenant boundaries

I usually ensure this by:

enforcing tenant_id filtering

using global query scopes or middleware

passing tenant context throughout the request lifecycle

👉 Missing this once can lead to serious data leaks

🧠 Design Considerations

Tenant Context

Identify tenant per request (subdomain, token, header)

Ensure it flows through the entire system

Authorization

Access control must be tenant-aware

Users should never access data outside their tenant

Scaling Strategy

small tenants → shared resources

large tenants → isolated resources

👉 I usually think in hybrid models

Data Lifecycle

schema changes must work across tenants

backup/restore should support tenant-level operations

Customization

support tenant-specific configuration (feature flags, settings)

avoid hardcoding tenant-specific logic

⚖️ Tradeoff Awareness

Multi-tenancy is always a balance between:

isolation

cost

complexity

There is no one-size-fits-all solution.

📌 Practical Rule

I always design with this assumption:

> tenant data must never leak across boundaries

If there is any chance of cross-tenant data exposure:

👉 the design is not acceptable

💬 Summary

For me, multi-tenancy is not just a database decision.

It directly impacts:

authorization

caching

architecture

deployment

When done correctly, it enables:

scalable SaaS systems

efficient resource usage

strong data isolation