Multi-Tenant - 05 - Checklists

Segue uma checklist prática pra você revisar/ajustar tudo.

1. Checklist por TABELA

Para cada tabela multi-tenant, confirme:

1. Coluna de tenant

   • tenant_id BIGINT NOT NULL existe.
   • Nunca é NULL (nem por migration, nem por código).

2. Primary Key

   • PK simples: id BIGSERIAL ou id UUID (o padrão que você escolheu).
   • Não está usando (tenant_id, id) como PK (a não ser em casos especiais).

3. Índice padrão multi-tenant

   • Índice criado:

CREATE INDEX nome_tabela_tenant_id_idx
  ON public.nome_tabela (tenant_id, id);

4. Unicidade de negócio por tenant

   • Toda regra de unicidade “de negócio” é por tenant, por ex.:

CREATE UNIQUE INDEX nome_tabela_uq_tenant_codigo
  ON public.nome_tabela (tenant_id, codigo);

• Nada está único “global” sem tenant (a não ser que faça sentido globalmente).

5. Auditoria

   • Colunas:

created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()

• Trigger set_updated_at configurada:

CREATE TRIGGER nome_tabela_set_updated_at
BEFORE UPDATE ON public.nome_tabela
FOR EACH ROW
EXECUTE FUNCTION set_updated_at();

6. RLS (Row Level Security)

   • RLS habilitado:

ALTER TABLE public.nome_tabela ENABLE ROW LEVEL SECURITY;

• Policy usando app.tenant_id:

CREATE POLICY nome_tabela_tenant_policy
ON public.nome_tabela
USING (tenant_id = current_settingBIGINT;

• (Opcional) Se precisar controlar INSERT também:

WITH CHECK (tenant_id = current_settingBIGINT;

7. Tabelas de junção (N:N)

   • Têm id como PK simples.
   • Têm tenant_id BIGINT NOT NULL.
   • Têm índice:

CREATE INDEX nome_juncao_tenant_id_idx
  ON public.nome_juncao (tenant_id, id);

• Têm UNIQUE pra evitar duplicidade:

CREATE UNIQUE INDEX nome_juncao_uq_tenant_a_b
  ON public.nome_juncao (tenant_id, a_id, b_id);

2. Checklist INFRA (DB/RLS)

1. Função de updated_at

   • set_updated_at() criada uma vez no schema.

2. Variável de sessão app.tenant_id

   • Todas as policies RLS usam:

current_setting('app.tenant_id')::BIGINT

3. Middleware de transação

   • Existe middleware que:

• Lê tenantID (rota/header).
• Abre BEGIN via db.BeginTxx(...).
• Executa SET LOCAL app.tenant_id = $1.
• Injeta a *sqlx.Tx no context (dbctx.WithTx).
• Faz COMMIT/ROLLBACK.

3. Checklist APLICAÇÃO (Go)

1. Contexto de tenant

   • Tem helper tipo httpcontext.WithTenantID / TenantIDFromContext.
   • Middleware HTTP que amarra tenantID à request (pra logs, etc).

2. Uso de Tx em repositórios

   • Pacote dbctx para guardar Tx no context.
   • Nos repositórios:

• Tipo DBTX criado (DB/Tx).
• Função runner(ctx) que retorna Tx se existir, senão DB.
• Todos os métodos usam db := r.runner(ctx).

3. Service / Domain

   • Todos os serviços recebem tenantID como parâmetro explícito.
   • Nenhum serviço “descobre” tenant sozinho (não busca direto do context).
   • Validações de negócio que comparam tenants (se houver) levam isso em conta.

4. Handlers (HTTP)

   • Todas as rotas multi-tenant incluem tenantID (no path ou header).
   • Handler converte tenantID para int64, valida > 0.
   • Handler sempre chama services passando tenantID.

4. Checklist de TESTES / VERIFICAÇÃO

1. Teste de isolamento entre tenants

   • Criar dados com tenant_id = 1 e tenant_id = 2.
   • Simular request com tenantID=1:

• Verificar que não retorna/atualiza registros do tenant_id=2.
• Repetir com tenantID=2.

2. Teste de “falha de WHERE tenant_id”

   • Criar uma query de propósito sem WHERE tenant_id no código (num repositório de teste).
   • Confirmar que RLS ainda impede acesso a outros tenants, porque está usando app.tenant_id.

3. Teste de erro de Tx

   • Forçar um erro (ex: inserir duplicado violando UNIQUE).
   • Verificar se o middleware deu ROLLBACK e não deixou lixo no banco.