Vibeship-spawner-skills multi-tenancy

id: multi-tenancy name: Multi-Tenancy category: enterprise description: Use when designing multi-tenant SaaS architectures, implementing tenant isolation, data partitioning strategies, or building billing/metering systems - covers pooled, siloed, and hybrid models

patterns: golden_rules: - rule: "Tenant ID everywhere" reason: "Must be in every query, log, metric" - rule: "Never trust tenant context" reason: "Validate at every layer" - rule: "Design for noisy neighbor" reason: "One tenant shouldn't affect others" - rule: "Metering from day one" reason: "Can't bill without usage data" - rule: "Plan for tenant lifecycle" reason: "Onboarding, offboarding, data export"

isolation_models: pooled: description: "Shared database with row-level security" cost: "Lowest" isolation: "Shared risk, complex RLS" use_when: "Cost-sensitive, many small tenants" schema_per_tenant: description: "Separate schema per tenant" cost: "Moderate" isolation: "Good isolation, migration complexity" use_when: "Moderate compliance needs" database_per_tenant: description: "Dedicated database per tenant" cost: "Higher" isolation: "Strong isolation, compliance friendly" use_when: "Enterprise customers, strict compliance" instance_per_tenant: description: "Dedicated infrastructure per tenant" cost: "Highest" isolation: "Full isolation, simple model" use_when: "Largest enterprise, regulated industries"

tenant_context_sources: - source: "Subdomain" example: "tenant.app.com" priority: 1 - source: "Header" example: "X-Tenant-ID" priority: 2 - source: "JWT claim" example: "token.tenant_id" priority: 3 - source: "Path parameter" example: "/tenants/{id}/..." priority: 4

metering_types: count: "Number of items (API requests)" gauge: "Current value (storage used)" sum: "Total accumulated (compute hours)"

lifecycle_states: - "provisioning" - "active" - "suspended" - "pending_deletion" - "deleted"

anti_patterns:

• pattern: "Missing tenant_id" problem: "Data leakage between tenants" solution: "Enforce tenant_id on all queries"
• pattern: "Trust client tenant" problem: "Security vulnerability" solution: "Validate tenant server-side"
• pattern: "No rate limiting" problem: "Noisy neighbor issues" solution: "Implement per-tenant limits"
• pattern: "Hardcoded isolation" problem: "Can't upgrade tenants" solution: "Design for flexible isolation"
• pattern: "No metering" problem: "Can't bill accurately" solution: "Meter from day one"
• pattern: "Manual provisioning" problem: "Slow onboarding" solution: "Automate tenant setup"

implementation_checklist: data_isolation: - "Isolation model chosen (pooled/schema/database)" - "Tenant ID on all data models" - "Row-level security implemented" - "Cross-tenant queries prevented" - "Tenant context validated at API layer" resource_management: - "Per-tenant quotas defined" - "Rate limiting implemented" - "Resource governor active" - "Noisy neighbor monitoring" - "Fair scheduling enabled" lifecycle: - "Onboarding automated" - "Suspension workflow" - "Data export capability" - "Deletion with retention" - "Audit trail for lifecycle events" operations: - "Per-tenant logging" - "Tenant-aware metrics" - "Isolated backups" - "Per-tenant health checks"

handoffs:

• skill: disaster-recovery trigger: "tenant data backup and recovery"
• skill: gdpr-privacy trigger: "tenant data privacy and deletion"

ecosystem: platforms: - "WorkOS" - "Frontegg" - "Clerk" - "Auth0 Organizations" databases: - "PostgreSQL RLS" - "Citus (distributed)" - "CockroachDB" - "PlanetScale" billing: - "Stripe Billing" - "Chargebee" - "Orb" - "Metronome"

sources: references: - "WorkOS Multi-Tenant Architecture Guide" - "Azure Multi-Tenant Patterns" - "Frontegg SaaS Multitenancy"