What this prompt does
This prompt implements multi-tenancy for a Spring Boot [spring_version] SaaS application using a [tenancy_strategy] strategy. It resolves the tenant from [tenant_source], propagates tenant context via ThreadLocal/MDC, routes the database dynamically, makes JPA repositories tenant-aware, runs Flyway migrations per tenant, exposes a tenant provisioning API, shares [shared_services] across tenants, adds tenant-aware caching with [cache_provider], ensures background jobs run in the right tenant context, and includes a testing strategy plus a security audit checklist for cross-tenant leak prevention.
The structure works because in multi-tenant SaaS, one leaked row between tenants is a serious incident, not a minor bug. The two parts the prompt insists on — propagating tenant context into async jobs and a dedicated leak-prevention checklist — are exactly where isolation silently breaks. A request-scoped ThreadLocal works until a background task runs without it; the prompt forces that case to be handled rather than discovered in production.
When to use it
- When building multi-tenant SaaS and tenant data must never cross boundaries
- When choosing or implementing a
[tenancy_strategy](database, schema, or row-level) - When tenants are resolved from
[tenant_source]like a subdomain or header - When background jobs must run in the correct tenant context, not a leaked one
- When onboarding new tenants needs an automated provisioning API
- When you need a concrete security checklist to audit for cross-tenant leaks
Example output
Expect a Spring Boot implementation: tenant resolution from [tenant_source], context propagation through the request lifecycle via ThreadLocal and MDC, dynamic DataSource routing for [tenancy_strategy], tenant-aware JPA repositories that filter automatically, per-tenant Flyway migrations, a provisioning API that sets up a new tenant's database or schema, shared [shared_services] that stay common across tenants, tenant-prefixed caching with [cache_provider], async-task context handling so background jobs run in the right tenant, and a security audit checklist for cross-tenant leak prevention. It includes edge cases like tenant-not-found and suspension rather than only the happy path, which is where isolation usually breaks.
Pro tips
- Pick
[tenancy_strategy]to match your isolation needs; schema-per-tenant balances isolation and cost, while database-per-tenant is stronger but heavier to operate - Never skip the async context handling — a background job that loses the tenant context is the classic way data leaks between tenants
- Run the leak-prevention checklist as a real review, not a formality; cross-tenant leaks are high-severity incidents
- Use tenant-prefixed keys in
[cache_provider]so one tenant can never read another's cached data - Handle tenant suspension and not-found explicitly so a missing or disabled
[tenant_source]fails safely instead of falling back to a default tenant - Test with multiple tenants simultaneously; bugs that only appear under concurrent multi-tenant load are easy to miss with single-tenant tests
