SaaS Architecture: Scenario-Based Questions

Multi-tenancy allows a single SaaS application instance to serve multiple customers (tenants) securely and efficiently. The challenge lies in balancing data isolation, cost, and scalability.

🏗️ Tenancy Models

• Shared Database, Shared Schema: All tenants in the same tables (most efficient, least isolated).
• Shared Database, Isolated Schema: One DB, separate schemas per tenant.
• Isolated Database per Tenant: Full isolation — more secure, costlier to scale.

🔐 Data Isolation & Security

• Always scope queries by tenant ID — enforce at DB and app layers.
• Use row-level security (PostgreSQL RLS) or ORM-level guards.
• Encrypt tenant-specific data at rest and in transit.
• Audit access per tenant — separate logs and metrics when possible.

🧰 Tenant Metadata Management

• Store tenant config centrally (plan, region, quotas, flags).
• Route users to their correct compute/db location based on subdomain, token, or IDP.
• Automate tenant onboarding and teardown via scripts or workflows.

📊 Observability & Limits

• Tag all logs, metrics, and traces by tenant.
• Enforce tenant-specific quotas (API rate limits, storage, CPU).
• Use dashboards to detect noisy or underperforming tenants.

✅ Best Practices

• Design for horizontal scaling — avoid shared bottlenecks.
• Use feature flags to roll out features tenant-by-tenant.
• Offer flexible upgrade paths (tiered plans, isolated infra).
• Support tenant-specific customizations without branching core logic.

🚫 Common Pitfalls

• Improper scoping of tenant queries — leads to data leaks.
• Mixing tenant logic deep in app code — makes refactoring hard.
• Underestimating blast radius of noisy neighbors in shared infra.

📌 Final Insight

Multi-tenancy design is a foundational SaaS decision. Get it right early — it affects scalability, security, pricing, and operations. The best systems make it invisible to tenants but crystal clear to engineers.