# SaaS - Arquitectura Multi-tenant

## Estrategias de Isolamento

### 1. Database per Tenant (Isolamento Maximo)

- Pros: Seguranca total, restore independente
- Contras: Custo, complexidade gestao
- Usar quando: Enterprise, regulamentacoes
- Exemplo: AWS RDS + Aurora Serverless

### 2. Schema per Tenant (Equilibrio)

- Pros: Bom isolamento, gestao simplificada
- Contras: Limites BD (PostgreSQL ~10k schemas)
- Usar quando: B2B medio porte
- Exemplo: PostgreSQL schemas dinamicos

### 3. Shared DB + Row-Level Security (Economico)

- Pros: Mais barato, facil escalar
- Contras: tenant_id em tudo, RLS obrigatorio
- Usar quando: B2C, SMB self-service
- Exemplo: PostgreSQL RLS policies

## Implementacao Row-Level Security (PostgreSQL)

```sql
-- 1. Adicionar tenant_id a todas as tabelas
ALTER TABLE users ADD COLUMN tenant_id UUID NOT NULL;
ALTER TABLE projects ADD COLUMN tenant_id UUID NOT NULL;
ALTER TABLE documents ADD COLUMN tenant_id UUID NOT NULL;

-- 2. Activar RLS
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

-- 3. Criar policy de isolamento
CREATE POLICY tenant_isolation ON users
    USING (tenant_id = current_setting('app.tenant_id')::uuid);

CREATE POLICY tenant_isolation ON projects
    USING (tenant_id = current_setting('app.tenant_id')::uuid);

-- 4. No inicio de cada request (backend)
-- SET app.tenant_id = 'uuid-do-tenant-autenticado';
```

## Checklist Seguranca Multi-tenant

```
[ ] tenant_id em TODAS as tabelas
[ ] RLS policies activas
[ ] Indexes em tenant_id (performance)
[ ] Validacao tenant_id no auth middleware
[ ] Logs de acesso cross-tenant
[ ] Testes de isolamento (tenant A nao ve tenant B)
```