Arquitetura multi-tenant para SaaS: conceitos e decisões

Arquitetura multi-tenant permite atender várias organizações com uma mesma plataforma, mantendo os dados e as permissões de cada cliente isolados. A decisão central não é apenas onde os dados ficam. É como o contexto do tenant acompanha identidade, consultas, arquivos, filas, cache, logs e tarefas administrativas sem abrir caminhos de acesso cruzado.

Resposta direta: qual modelo escolher

Use o modelo pool quando eficiência e operação compartilhada são prioritárias e o domínio aceita políticas granulares bem testadas. Use silo quando isolamento, requisitos contratuais ou risco justificam recursos dedicados. O modelo bridge combina elementos: por exemplo, aplicação compartilhada com schema ou banco separado. A escolha pode variar por plano ou sensibilidade do cliente.

A AWS ressalta que autenticação e autorização de função não bastam para isolamento. Um usuário pode estar autenticado e autorizado a usar uma funcionalidade, mas ainda assim acessar recursos de outro tenant se o contexto organizacional não for aplicado em cada operação.

Modele identidade e pertencimento primeiro

Separe usuário de organização. Uma pessoa pode pertencer a mais de um tenant e ter papel diferente em cada um. Um modelo comum inclui organizations, memberships, roles e as entidades do domínio com organization_id. O tenant ativo deve ser resolvido no servidor a partir de uma associação válida, nunca aceito apenas de um campo enviado pelo navegador.

Tokens podem carregar contexto, mas mudanças de associação e revogação precisam ser consideradas. Para operações sensíveis, confirme pertencimento atual no servidor ou no banco. Chaves administrativas não devem ser expostas ao cliente.

RLS como defesa em profundidade

No PostgreSQL/Supabase, Row Level Security aplica políticas a cada acesso à tabela. A documentação oficial recomenda habilitar RLS em tabelas de schemas expostos. Em uma aplicação multi-tenant, políticas normalmente relacionam a linha ao tenant e verificam a associação do usuário.

RLS não substitui desenho de API, validação ou testes. Ela cria uma barreira adicional caso uma consulta esqueça um filtro. Índices nas colunas usadas pelas políticas são importantes para evitar que segurança se transforme em gargalo. Operações com service_role ou privilégios que ignoram RLS exigem caminhos separados, logs e revisão mais rigorosa.

O contexto precisa atravessar toda a arquitetura

• Banco: todas as entidades pertencentes ao cliente têm chave de tenant.
• Storage: caminhos e políticas incluem organização, não apenas usuário.
• Cache: a chave contém tenant e permissões relevantes.
• Filas: cada mensagem registra tenant e identidade da operação.
• Busca: índices e filtros preservam o limite organizacional.
• Logs: tenant aparece para investigação, sem expor dados indevidos.
• Métricas: consumo é atribuído ao tenant para custo e limites.
• Administração: ações privilegiadas têm motivo, ator e trilha de auditoria.

Um vazamento pode ocorrer fora do banco. Um cache compartilhado com chave incompleta ou um job assíncrono sem contexto pode devolver dados corretos para o cliente errado.

Estratégia de testes

Crie pelo menos dois tenants em testes automatizados. Para cada consulta e mutação, prove o acesso permitido e também a negação cruzada. Teste listagem, busca por ID conhecido, atualização, exclusão, arquivos, exports, jobs e rotas administrativas.

Inclua cenários de mudança de tenant, convite revogado, usuário sem associação, IDs manipulados e tentativa de usar recurso criado por outra organização. Em RLS, teste as políticas diretamente no banco com papéis equivalentes aos da aplicação. Backups e restauração também precisam preservar pertencimento.

Quando migrar de pool para bridge ou silo

Não migre apenas por crescimento abstrato. Procure sinais: requisitos contratuais, residência de dados, clientes com carga desproporcional, necessidade de janela própria, recuperação isolada ou personalização que ameaça o modelo compartilhado. Desenhe desde cedo identificadores e automação de provisionamento que permitam mover um tenant sem reescrever o domínio.

Checklist de revisão

• Tenant explícito nas entidades, arquivos, filas e caches.
• Pertencimento validado no servidor e no banco.
• RLS habilitada e testada nas tabelas expostas.
• Índices compatíveis com filtros e políticas.
• Nenhuma chave privilegiada no navegador.
• Testes negativos entre dois ou mais tenants.
• Logs de ações administrativas e alterações críticas.
• Métricas e limites por organização.
• Backup e restauração testados.
• Plano documentado para mover ou isolar tenants.

Fontes primárias

• AWS: SaaS Tenant Isolation Strategies
• AWS: Tenant isolation em SaaS
• AWS: Guidance for Multi-Tenant Architectures
• Supabase: Row Level Security

Veja também os cuidados de segurança e LGPD em SaaS e nossa abordagem de desenvolvimento de plataformas SaaS.