Multi-Tenant SaaS Architecture

Multi-tenancy is serving many customers from one logical system. The central question never changes: how strongly are tenants isolated, and what does that isolation cost you to operate?

The isolation spectrum

Most platforms start shared-schema with a tenant_id on every row, and graduate only specific large or regulated tenants to dedicated databases.

Making shared-schema safe

One query missing its tenant_id filter leaks one customer's data to another. Defenses, weakest to strongest:

1. A repository layer that injects tenant_id so application code can't forget it.
2. Tests that assert cross-tenant queries return nothing.
3. Row-level security in the database, scoped to a session variable. The database refuses another tenant's rows even when the query is wrong.

Row-level security is the one that lets you sleep, because it fails closed.

Onboarding is data, not deployment

Lesson. If adding a customer means standing up an environment, you've built single-tenant software you happen to run many times. Adding a tenant should be a row, not a deploy.

This is what makes the model economical. It also forces good discipline: tenant configuration, credentials, branding, and limits all become data.

Cross-cutting concerns

• Auth carries the tenant — usually a claim resolved to a tenant context at the edge of every request.
• Noisy neighbors — one tenant's load must not starve others. Rate limit and queue per tenant.
• Isolation runs end to end — not just the database. The same boundary applies to file storage, queues, and processing.

Where it connects

This underpins enterprise integration work: each customer is a tenant with isolated documents, credentials, and dashboards, served from one platform — the same boundary used by the SFTP integration platform, serving 40+ enterprise customers from shared infrastructure.