System Design FAQ: Top Questions

A Multi-Tenant SaaS Platform allows multiple organizations (tenants) to use a single software deployment while keeping their data logically isolated and secure.

📋 Functional Requirements

• Tenant-based data isolation
• Per-tenant configuration (themes, limits)
• Tenant-aware authentication & authorization
• Billing, onboarding, audit logs per tenant

📦 Non-Functional Requirements

• Horizontal scalability
• Security and access control enforcement
• Custom domains and rate limits

🏗️ Multi-Tenancy Models

• Shared DB, Shared Schema: Fastest, single schema with tenant_id field
• Shared DB, Separate Schema: Better isolation, harder upgrades
• Separate DB per tenant: Strongest isolation, complex scaling

🧪 PostgreSQL Row-Level Isolation

CREATE POLICY tenant_isolation_policy
  ON customers
  FOR ALL
  USING (tenant_id = current_setting('app.current_tenant')::uuid);
        

SET app.current_tenant = 'tenant-123';
SELECT * FROM customers; -- returns only tenant-123's data
        

🔐 Tenant-Aware Auth

• JWT contains tenant_id claim
• Every API validates tenant context

🧱 Directory Structure for Logical Isolation

src/
  tenants/
    tenantA/
    tenantB/
  shared/
  configs/
        

🧾 Billing Hooks

• Per-tenant usage metering
• Stripe webhook: invoice.paid, subscription.updated

📈 Observability Per Tenant

• Per-tenant metrics: API usage, error rates, latency
• Per-tenant audit and access logs

🧰 Tools & Tech Stack

• Database: PostgreSQL, DynamoDB with partition key
• Auth: Auth0, Firebase, Cognito with custom claims
• Monitoring: Datadog, Prometheus + tenant tags
• Billing: Stripe with metadata: tenant_id

📌 Final Insight

Multi-tenancy allows economies of scale while introducing challenges in isolation and configuration. Choose the right data model based on tenant volume and security needs. Enforce isolation at all layers: auth, queries, logs, and storage.