Skip to main content

Agentic SaaS Platform with Multi-Tenancy

Standard SaaS Multi-Tenancy Approach

Note: This is generated content. Please refer valid sources while implementing.

What is Multi-Tenancy?

Multi-tenancy is a software architecture pattern in which a single application platform serves multiple customers (tenants) while ensuring that each tenant's users, data, configurations, sessions, and workloads remain isolated from those of other tenants. A tenant typically represents a customer organization, business unit, or client. Although tenants may share parts of the underlying infrastructure (such as application services, compute clusters, or monitoring systems), the platform enforces strict logical or physical boundaries to prevent unauthorized access, data leakage, and performance interference across tenants.

A common enterprise SaaS architecture uses shared infrastructure with logical tenant isolation, while introducing stronger isolation controls when required for compliance, regulatory, security, or performance reasons.

High-Level Architecture

                     Shared SaaS Platform
┌─────────────────────────────────────────────┐
│ API Gateway                                 │
│ App Services / AKS                          │
│ Agent Orchestration Layer                   │
│ Monitoring / Logging                        │
└─────────────────────────────────────────────┘
                    │
        ┌───────────┼───────────┐
        │           │           │
        ▼           ▼           ▼
   Tenant A    Tenant B    Tenant C
   (Client A)  (Client B)  (Client C)

The application serves multiple customers (tenants) from the same platform while ensuring that data, sessions, and workloads remain isolated.

1. Identity Isolation

Users authenticate through an Identity Provider such as Microsoft Entra ID.

User Login
   ↓
Entra ID
   ↓
JWT Token
   ↓
Tenant Claim
   ↓
Application Authorization

The platform determines:

  • Which tenant the user belongs to
  • What resources the user can access
  • Which data the user can view
  • Which agents or services the user can invoke

Note: Entra Tenant ID may be used for authentication and tenant identification, but it is typically only one part of the overall tenant isolation strategy.

2. Data Isolation

Model A: Shared Database (Most Common)

All tenants share the same database, with records tagged using a tenant identifier.

Users

TenantId | UserId | Name
A        | 101    | John
B        | 102    | Mike

All queries are filtered by tenant context.

SELECT *
FROM Documents
WHERE TenantId = @CurrentTenant

Pros

  • Lower cost
  • Easier operations
  • Better resource utilization

Cons

  • Requires strong authorization and access controls

Model B: Database Per Tenant

Client A → DB_A
Client B → DB_B
Client C → DB_C

Pros

  • Strong isolation
  • Easier compliance discussions

Cons

  • Higher operational overhead
  • Increased cost

Model C: Hybrid Model

Very common in enterprise SaaS platforms.

Small / Standard Clients
        ↓
Shared Database

Regulated / Premium Clients
        ↓
Dedicated Database
Dedicated Storage

3. Agent Session Isolation

For AI-enabled platforms, agent isolation is critical.

Each session is scoped using:

TenantId
UserId
SessionId

This ensures:

  • Conversation history remains isolated
  • Agent memory is tenant-specific
  • Runtime context cannot leak across clients
  • Prompts and responses are tenant-bound

Example:

Client A
 └─ User A
     └─ Session A1

Client B
 └─ User B
     └─ Session B1

Agent memory from Client A should never be accessible to Client B.

4. Vector Store / RAG Isolation

In GenAI architectures, embeddings and indexed documents must be isolated.

Shared Vector Store with Partitions

Vector Index
├── Tenant A
├── Tenant B
└── Tenant C

Dedicated Vector Stores

Vector DB A
Vector DB B
Vector DB C

This prevents retrieval of another tenant's documents during RAG (Retrieval-Augmented Generation).

5. Compute Isolation

Application compute is often shared.

AKS Cluster
 ├─ Tenant A Requests
 ├─ Tenant B Requests
 └─ Tenant C Requests

Isolation is typically achieved using:

  • Kubernetes namespaces
  • Resource quotas
  • Rate limiting
  • Autoscaling
  • Workload scheduling policies

For high-security or premium customers:

Dedicated AKS Cluster
or
Dedicated Deployment

may be provided.

6. Storage Isolation

Shared Storage

Storage Account
 ├─ tenant-a/
 ├─ tenant-b/
 └─ tenant-c/

Dedicated Storage

Storage Account A
Storage Account B
Storage Account C

The chosen model depends on security, compliance, and customer requirements.

7. Shared vs Dedicated Components

Shared Components

  • API Gateway
  • Application Services
  • AKS/App Services
  • Monitoring & Logging
  • CI/CD Pipelines
  • Agent Orchestration Services
  • Identity Integration Components

Potentially Dedicated Components

  • Databases
  • Blob Storage
  • Key Vaults
  • Vector Databases
  • AI Models/Deployments
  • Compute Resources

Typical Enterprise Architecture Response

In a standard SaaS multi-tenant architecture, a client (tenant) is isolated through application-level tenant controls rather than completely separate infrastructure. User identity is mapped to a tenant, and all data access, agent sessions, vector indexes, and workload execution are scoped to that tenant. Infrastructure such as API gateways, application services, Kubernetes clusters, and monitoring platforms is often shared across tenants, while customer data stores, storage accounts, vector databases, or compute resources may be logically or physically separated depending on security, compliance, and performance requirements. Entra Tenant ID may be used for identity federation, but the primary concern is application-level tenant isolation across data, sessions, and workloads.

No comments to display

Back to top