Use when choosing multi-tenant architecture patterns. Covers Pool (shared), Silo (isolated), and Bridge (hybrid) models with decision frameworks for isolation, cost, and scale trade-offs.
Provides decision frameworks for choosing multi-tenant architecture patterns (Pool, Silo, Bridge) based on isolation requirements, cost constraints, and scale. Use when designing SaaS applications or evaluating shared vs. dedicated infrastructure trade-offs.
/plugin marketplace add melodic-software/claude-code-plugins/plugin install saas-patterns@melodic-softwareThis skill is limited to using the following tools:
references/bridge-model.mdreferences/pool-model.mdreferences/silo-model.mdArchitecture patterns for deploying multi-tenant SaaS applications, from fully shared to fully isolated.
Multi-tenancy spectrum:
Fully Shared (Pool) Hybrid (Bridge) Fully Isolated (Silo)
◄──────────────────────────────────────────────────────────────►
Low Cost High Cost
Low Isolation High Isolation
High Density Low Density
Noisy Neighbor Risk No Interference
┌─────────────────────────────────────────────────────┐
│ Application Layer │
│ All tenants share compute, storage, database │
├─────────────────────────────────────────────────────┤
│ Database │
│ ┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐ │
│ │ T1 │ T2 │ T3 │ T4 │ T5 │ T6 │ T7 │ ... │ │
│ └─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┘ │
│ (Row-Level Security separates data) │
└─────────────────────────────────────────────────────┘
Characteristics:
- Single database, shared schema
- Row-level security for isolation
- All tenants share compute resources
- Lowest cost per tenant
- Highest tenant density (millions possible)
Best For:
Challenges:
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Tenant A │ │ Tenant B │ │ Tenant C │
│ ┌────────────┐ │ │ ┌────────────┐ │ │ ┌────────────┐ │
│ │ App │ │ │ │ App │ │ │ │ App │ │
│ ├────────────┤ │ │ ├────────────┤ │ │ ├────────────┤ │
│ │ Database │ │ │ │ Database │ │ │ │ Database │ │
│ └────────────┘ │ │ └────────────┘ │ │ └────────────┘ │
└──────────────────┘ └──────────────────┘ └──────────────────┘
Characteristics:
- Dedicated resources per tenant
- Complete data isolation
- Independent scaling
- Independent maintenance windows
- Highest cost per tenant
Best For:
Challenges:
┌─────────────────────────────────────────────────────────────────┐
│ Shared Services │
│ (Authentication, Billing, Monitoring, Configuration) │
└─────────────────────────────────────────────────────────────────┘
│ │
┌───────────┴───────────┐ ┌───────┴───────┐
│ Pooled Tier │ │ Premium Tier │
│ ┌────┬────┬────┐ │ │ ┌─────────┐ │
│ │ T1 │ T2 │ T3 │ │ │ │ Tenant │ │
│ └────┴────┴────┘ │ │ │ (Silo) │ │
│ (Shared Database) │ │ └─────────┘ │
└───────────────────────┘ └───────────────┘
Characteristics:
- Shared control plane
- Mix of pool and silo at data plane
- Tenant tiering (Standard = Pool, Premium = Silo)
- Gradual migration path from pool to silo
Best For:
Start
│
┌───────────┴───────────┐
│ Strict compliance │
│ requirements? │
└───────────┬───────────┘
Yes ──┤──── No
│ │
┌────▼────┐ │
│ SILO │ │
└─────────┘ │
┌─────▼─────┐
│ >10,000 │
│ tenants? │
└─────┬─────┘
Yes ────┤──── No
│ │
┌────▼────┐ ┌────▼────┐
│ POOL │ │ BRIDGE │
└─────────┘ └─────────┘
| Factor | Weight | Pool Score | Silo Score | Bridge Score |
|---|---|---|---|---|
| Cost Efficiency | 25% | 5 | 1 | 3 |
| Tenant Isolation | 20% | 2 | 5 | 4 |
| Scalability | 20% | 5 | 3 | 4 |
| Operational Simplicity | 15% | 4 | 2 | 3 |
| Customization | 10% | 2 | 5 | 4 |
| Compliance Fit | 10% | 2 | 5 | 4 |
| Aspect | Pool | Silo | Bridge |
|---|---|---|---|
| Scale | 1-1,000,000+ | 1-1,000s | 1-100,000s |
| Cost per Tenant | Lowest | Highest | Variable |
| Isolation | Low (logical) | Complete | Tiered |
| Noisy Neighbor Risk | High | None | Varies by tier |
| Onboarding Speed | Instant | Minutes-Hours | Varies by tier |
| Schema Customization | None | Full | Limited/Full |
| Compliance | Shared controls | Dedicated | Hybrid |
| Operational Complexity | Low | High at scale | Medium |
Key Components:
1. Tenant Resolver Middleware
- Extract tenant from subdomain, header, or JWT claim
- Set tenant context for request
2. Row-Level Security
- Database-level isolation (SQL Server RLS, PostgreSQL RLS)
- All queries filtered by tenant_id
3. Shared Connection Pool
- Single connection string
- Tenant context passed per-request
4. Global Query Filters (EF Core)
- Automatic tenant filtering on all entities
See database-isolation skill for implementation details.
Key Components:
1. Tenant Routing
- DNS-based (tenant.app.com)
- API Gateway routing by tenant identifier
2. Dedicated Infrastructure
- Database per tenant
- Optionally dedicated compute
3. Tenant Catalog
- Central registry of tenant configurations
- Connection strings, feature flags, customizations
4. Infrastructure as Code
- Automated provisioning (Terraform, Bicep)
- Template-based tenant environments
See tenant-provisioning skill for implementation details.
Key Components:
1. Tiered Tenant Classification
- Standard tier → Pool
- Premium tier → Silo
2. Unified Control Plane
- Single admin portal
- Central configuration management
- Aggregated monitoring
3. Data Plane Routing
- Route to pool or silo based on tier
- Seamless upgrade path (pool → silo)
4. Migration Support
- Data export from pool
- Import to dedicated resources
- Zero-downtime migration
| Model | Services |
|---|---|
| Pool | Azure SQL with RLS, Elastic Pools |
| Silo | SQL Database per tenant, Cosmos DB account per tenant |
| Bridge | Mix of above, Azure Front Door for routing |
| Model | Services |
|---|---|
| Pool | RDS PostgreSQL with RLS, DynamoDB with partition key |
| Silo | RDS per tenant, isolated VPCs |
| Bridge | Mix of above, API Gateway for routing |
| Isolation Level | Pattern | Cost | Isolation |
|---|---|---|---|
| Partition key per tenant | Shared container | Lowest | Logical |
| Container per tenant | Shared database | Medium | Container RBAC |
| Database per tenant | Shared account | Higher | Database RBAC |
| Account per tenant | Dedicated account | Highest | Complete |
Phase 1: MVP (Pool)
└── Single database, RLS
└── Minimize costs
└── Validate product-market fit
Phase 2: Growth (Bridge)
└── Introduce premium tier (Silo)
└── Keep standard tier (Pool)
└── First enterprise customers
Phase 3: Scale (Optimized Bridge)
└── Cell-based architecture
└── Regional deployment
└── Per-tenant SLA options
Move from Pool → Bridge when:
Move from Bridge → More Silo when:
| Anti-Pattern | Problem | Solution |
|---|---|---|
| Over-isolation early | High cost, slow development | Start with pool, migrate later |
| No tenant context | Data leakage risk | Always validate tenant context |
| Shared secrets | Cross-tenant access | Tenant-scoped encryption keys |
| Global caching | Cache pollution | Tenant-prefixed cache keys |
| Synchronous provisioning | Slow onboarding | Async provisioning with status |
1. Tenant Context is Sacred
- Validate on every request
- Never assume tenant from client input
- Log tenant ID with every operation
2. Defense in Depth
- Application-level filtering
- Database-level RLS
- Network-level isolation (for silo)
3. Observability per Tenant
- Metrics tagged by tenant
- Per-tenant dashboards
- Alerting thresholds per tier
4. Cost Attribution
- Track resource usage per tenant
- Enable chargebacks for enterprise
- Monitor for cost anomalies
5. Test Isolation
- Automated cross-tenant access tests
- Penetration testing for isolation
- Chaos testing for noisy neighbor
database-isolation - Implementation patterns for data isolationtenant-context-propagation - Context resolution in microservicesnoisy-neighbor-prevention - Resource isolation techniquestenant-provisioning - Automated tenant onboardingreferences/pool-model.md for detailed Pool implementationreferences/silo-model.md for detailed Silo implementationreferences/bridge-model.md for detailed Bridge implementationLast Updated: 2025-12-26
Use when working with Payload CMS projects (payload.config.ts, collections, fields, hooks, access control, Payload API). Use when debugging validation errors, security issues, relationship queries, transactions, or hook behavior.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.