Multi-tenancy на собеседовании системного аналитика

Зачем multi-tenancy

SaaS — many customers (tenants) на one application instance. Cost-efficient.

Trade-offs. Cost vs isolation.

Shared DB, shared schema

Все tenants в same tables. tenant_id колонка filters.

SELECT * FROM orders WHERE tenant_id = 42;

Pros: cheapest. Maintenance simple.

Cons:

• Risk leak (forget filter).
• Customization сложно.
• Noisy neighbor (один tenant — 99% load).
• Compliance (одна table = всё).

Use Row-Level Security (RLS) для defense.

Shared DB, separate schemas

Каждый tenant — own schema (set tables).

db.tenant_42.orders
db.tenant_99.orders

Pros:

• Better isolation.
• Per-tenant schema customization possible.

Cons:

• Каждая schema migration — N tenants apply.
• Connection pool tricky.

Separate DB per tenant

Каждый tenant — own DB instance.

Pros:

• Full isolation.
• Independent scale, customization.
• Compliance friendly (regional).

Cons:

• Highest cost.
• Operational overhead (N DBs).
• Cross-tenant analytics — hard.

Часто для enterprise tier (premium customers).

Hybrid

Mixed approach. Enterprise customers — separate DB. SMB — shared schema.

Common pattern для SaaS scaling.

Cross-cutting concerns

Authentication. Tenant resolution — domain-based (acme.app.com), header-based, JWT claim.

Resource limits. Per-tenant quotas — API rate limits, storage.

Backups. Per-tenant restore без affecting others.

Monitoring. Per-tenant metrics, alerting.

Customization.

• Feature flags per tenant.
• Branding per tenant.
• Custom fields / forms.

Связанные темы

• Database sharding для DE
• Stakeholder analysis для SA
• SLA SLO SLI для SA
• Feature flags для SA
• Подготовка к собесу системного аналитика

FAQ

Это официальная информация?

Нет. Статья основана на индустриальных SaaS practices.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.