تصميم منصات SaaS متعددة المستأجرين قابلة للتوسع

Multi-tenancy is the architectural decision that shapes almost every other part of a SaaS platform. It determines how data is isolated, what each customer costs to serve, how quickly you can onboard, which compliance commitments you can make, and how far a single incident can spread. It is also one of the hardest decisions to reverse once customers depend on the platform.

There is no single correct model. A platform serving thousands of small businesses has different constraints from one serving a few dozen regulated enterprises, and many platforms must serve both. The goal is to choose deliberately, enforce isolation in more than one layer, and keep the option to move tenants between models as the business changes.

Silo, pool, and bridge

AWS's SaaS guidance popularized three terms that are now widely used to describe tenancy models:

• Silo: each tenant gets dedicated resources — often its own database and sometimes its own compute stack. Isolation is strong and easy to explain to auditors, per-tenant customization and data residency are straightforward, and noisy neighbors are largely eliminated. The costs are higher infrastructure spend per tenant, deployment fan-out across many stacks, and an operating model that must automate everything to scale.
• Pool: tenants share infrastructure and schema, and every row is tagged with a tenant identifier. Unit costs are low, operations are uniform, and onboarding is fast. Isolation is enforced in software, so a missing filter is a data breach, and one heavy tenant can degrade service for everyone else.
• Bridge: a deliberate mix. A shared application tier may sit over schema-per-tenant or database-per-tenant storage, or the platform may pool standard-tier customers while siloing enterprise customers who pay for dedicated resources.

Many platforms end up in bridge territory because their pricing tiers demand it. The engineering implication is that tenancy should be a property managed by a control plane — a tenant registry recording each tenant's tier, region, storage location, and keys — rather than an assumption hard-coded across services. That is what makes it possible to migrate a growing customer from the pool to a dedicated silo without rewriting the application.

Carry tenant context everywhere

Resolve tenant identity once, at the edge, from the authenticated token — for example a tenant claim issued by your identity provider — and never from a request body, query string, or header the client controls. Propagate that context through every internal call, message, scheduled job, log line, and trace span.

Cross-tenant leaks seldom happen in the main request path, which is usually well tested. They happen in background jobs that process batches across tenants, event consumers that forget to set context, caches keyed without the tenant, shared search indexes, exports, and analytics pipelines. Make tenant context a required parameter of your data-access layer, so code that omits it fails to compile or fails at runtime instead of silently querying everything.

Enforce isolation in the database, not only in code

In pooled PostgreSQL deployments, row-level security provides defense in depth: even if application code omits a filter, the database refuses to return or write another tenant's rows.

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
ALTER TABLE invoices FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = NULLIF(current_setting('app.tenant_id', true), '')::uuid)
  WITH CHECK (tenant_id = NULLIF(current_setting('app.tenant_id', true), '')::uuid);

-- Application role: not the table owner, no BYPASSRLS attribute
GRANT SELECT, INSERT, UPDATE, DELETE ON invoices TO app_user;

-- Per request, inside a transaction, using the tenant from the verified token
BEGIN;
SELECT set_config('app.tenant_id', $1, true);  -- true = transaction-local
SELECT id, total FROM invoices WHERE status = 'open';
COMMIT;

Several details matter. The application must connect with a role that does not own the tables and lacks the BYPASSRLS attribute; FORCE ROW LEVEL SECURITY also applies the policy to the table owner, which protects against migrations or tools that run as owner. Setting the tenant with set_config and its transaction-local flag (equivalent to SET LOCAL, but parameterizable) means the value cannot leak to the next request on a pooled connection. Wrapping the lookup in NULLIF means a connection without tenant context simply sees no rows — a predictable, fail-closed behavior. Put tenant_id first in composite indexes so tenant-scoped queries stay efficient, and add automated tests that deliberately attempt cross-tenant reads and writes on every build.

Contain noisy neighbors

In pooled and bridged models, tenants compete for the same resources. Fairness has to be engineered at each layer:

• Edge: per-tenant rate limits and quotas at the API gateway, typically token buckets sized by tier.
• Background work: per-tenant queues or fair scheduling, so one tenant's bulk import cannot starve everyone else's jobs.
• Database: statement timeouts, connection limits per service, and review of tenant-scoped query patterns.
• Caching: keys namespaced by tenant, with per-tenant memory limits so one large tenant cannot evict everyone else's working set.
• Cells: partitioning tenants across independent cells — complete copies of the stack, each serving a subset of tenants — limits the blast radius of any failure and gives you a natural unit for relocating heavy tenants.

Encryption, keys, and compliance

Per-tenant data keys, managed through envelope encryption with a cloud key management service, give each tenant a cryptographic boundary in addition to a logical one. They also make offboarding cleaner: destroying a tenant's key renders data encrypted under it unreadable, including backup copies. Enterprise customers may ask to supply and control their own keys. That is a reasonable request, but design for its consequence: if a customer revokes the key, their service stops, and the platform must degrade gracefully for that tenant without affecting anyone else.

Data residency requirements map naturally onto regional cells. Keep the tenant registry authoritative about where each tenant's data lives, and make sure backups, logs, search indexes, and analytics copies respect the same boundaries. Those secondary stores are easy to overlook and are exactly where residency commitments tend to be tested in audits.

Engineer the tenant lifecycle

Tenancy is not only a runtime concern. Each stage of a tenant's life needs automation:

1. Onboarding: idempotent provisioning through the control plane — registry entry, keys, identity configuration, default data, and, for siloed tiers, infrastructure.
2. Operation: metering usage by tenant for billing and capacity planning, plus per-tenant observability. Tag logs and traces with the tenant ID; for metrics, aggregate by tier or cell to keep cardinality manageable, and drill into individual tenants through traces.
3. Change: tier upgrades, region moves, and silo migrations as routine, rehearsed operations rather than one-off projects.
4. Offboarding: data export in a documented format, a defined retention period, deletion across primary stores, indexes, caches, and object storage, and key destruction where per-tenant keys are used.

Choosing with the future in mind

The right tenancy model is the one that fits your customers today and can evolve as they change. Start with the simplest model your security and compliance commitments allow, enforce isolation in more than one layer, and invest early in the control plane, because it is what turns tenancy from a fixed architecture into a manageable property.

Treating tenant context, lifecycle, and fairness as first-class concerns from the start avoids the most expensive rework a SaaS team can face: retrofitting isolation into a system that was never designed for it, while customers are already using it.