multi-tenancylisted

# Multi-tenancy Two failure classes define the design: a tenant seeing another's data (catastrophic, reputational) and a tenant consuming another's capacity (gradual, contractual). Address both explicitly. ## Method 1. **Choose the isolation model per tier, not ideologically.** Shared tables with tenant_id: cheapest, scales to millions of tenants. Schema-per-tenant: middling isolation, migration fan-out pain beyond hundreds. Database-per-tenant: strongest isolation and per-tenant restore, real cost; sell it as the enterprise tier. Mixing models (shared for small, dedicated for large) is normal. 2. **Enforce tenancy below the application when possible.** Postgres row-level security with `tenant_id = current_setting(...)`, set per request from the authenticated context, turns a forgotten WHERE clause from a breach into a bug. Without RLS: repository-layer scoping that raw queries cannot bypass, and no ORM escape hatches in handlers. 3. **Carry tenant context, never accept it.** Tenant comes from the auth token/session, flows through request context to queries, jobs, and logs. Any endpoint taking tenant_id as a parameter from the client is an IDOR generator (see authz-design). 4. **Scope everything tenant-shaped.** Object storage prefixes, cache keys, search indexes, queue messages (tenant in payload, re-asserted at consumption), rate limits, encryption keys where contracts demand it. Cross-tenant leaks love the secondary stores