Multi-Tenant Architecture: What Is It?

An explanation of what multi-tenancy is, why it's used, and the common isolation models — shared, isolated, and hybrid.

Multi-tenant architecture is a software design pattern where a single instance of an application serves multiple tenants (customers) while keeping their data isolated and secure.

In a healthcare context, tenants could be:

• Individual hospitals or health systems (B2B)
• Different departments within a hospital (radiology, pathology)
• Research organizations accessing shared AI models
• Regional healthcare networks with specific compliance requirements

• Cost efficiency: Amortize expensive infrastructure across tenants
• Rapid deployment: Onboard new tenants in hours vs. months
• Consistent updates: Deploy AI model improvements to all tenants simultaneously
• Economies of scale: Centralized monitoring, security, and compliance
• Regulatory compliance: Different regions (EU/GDPR, US/HIPAA, state-specific)
• Data residency: Keep patient data within geographical boundaries
• Model sharing: Share base AI models while protecting proprietary fine-tuning

Tenant isolation is a spectrum — it can run from fully isolated to fully shared, or a mix of both approaches.

All tenants share the same infrastructure with logical separation.

Architecture:
  - Single Azure OpenAI instance
  - Shared Azure AI Search index with tenant filters
  - Single Postgres DB with schema per tenant

Pros:

• Lowest cost per tenant
• Simple feature rollouts
• Unified monitoring

Cons:

• Noisy neighbor risk (one hospital's bulk processing affects others)
• Complex data separation logic
• Single point of failure

Healthcare use case: Clinical documentation assistant for small clinics

• Shared LLM endpoints with rate limiting per tenant
• Tenant data separated by partition keys
• Cost-effective for practices with <100 providers

Each tenant gets dedicated infrastructure.

Pros:

• Maximum security and compliance
• No noisy neighbor issues
• Tenant-specific SLAs and scaling
• Easy per-tenant cost tracking

Cons:

• Highest cost (3-5x shared model)
• Complex fleet management
• Slower feature rollouts

Healthcare use case: Large health systems with strict compliance

• Mayo Clinic, Kaiser Permanente-level deployments
• Complete data and compute isolation
• Custom AI model fine-tuning per organization

Different service tiers with varying isolation levels.

Tiers:
  Basic:
    - Shared compute/storage
    - Standard compliance
  Premium:
    - Dedicated compute
    - Shared storage with encryption
  Enterprise:
    - Fully isolated stack
    - Custom compliance

Pros:

• Some cost sharing benefits
• Deploy less expensive resources for different customers
  • Tenant A could be a trial-user environment and tenant B a paying-customer environment
• Pricing per tenant

Cons:

• Codebase complexity to address single-tenant and multi-tenant cases
• Migrating users from one tier to another can be challenging
• Tracking which tenants are on which deployments adds monitoring overhead

Healthcare use case: Tiered AI platform

• Basic tier: Small practices using shared clinical NLP models
• Premium tier: Regional hospitals with dedicated GPU compute
• Enterprise tier: National health systems with full isolation

Shares some components, isolates others.

• Example: Tenants A, B, and C all use a shared web server, but each tenant gets its own dedicated DB

Architecture:
  Shared:
    - API Gateway
    - Authentication service
    - Base AI models
  Isolated per tenant:
    - Databases
    - Fine-tuned models
    - Storage accounts

Pros:

• Helps mitigate noisy neighbor risk, since some users may run expensive DB queries
• Components can be tailored to tenant needs

Cons:

• Managing deployments across shared and isolated components can become a challenge
• Performance metrics are harder to compare across tenants on different components

• https://www.ibm.com/think/topics/multi-tenant
• https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/considerations/tenancy-models
• https://learn.microsoft.com/en-us/azure/architecture/antipatterns/noisy-neighbor/noisy-neighbor