Por que multi tenancy e decisao de arquitetura, nao recurso
Toda plataforma que atende varios clientes em uma instalacao precisa responder a uma pergunta central: como garantir que o dado de um cliente nunca apareca para outro. Isso nao se acrescenta depois; e uma decisao que toca quase toda consulta, todo relatorio e todo upload.
Erros nessa camada nao sao bugs comuns: um bug funcional quebra um recurso, um bug de isolamento vaza dados de clientes, e reputacao nao se recupera rapido disso.
Tres padroes de isolamento
- Banco separado por cliente: isolamento mais forte e facil de explicar, mas caro de operar.
- Schema separado no mesmo banco: meio termo, com possiveis problemas de desempenho em grande numero de schemas.
- Tabelas compartilhadas com coluna de tenant: mais eficiente e escalavel, porem mais exposto a erro humano.
Para CRMs de conversa o padrao compartilhado costuma ser o pratico, desde que a aplicacao do filtro seja sistematica e nao dependa da memoria do desenvolvedor.
Defesas em camadas
- Na camada de acesso a dados, com filtro de tenant adicionado automaticamente.
- No middleware, com identidade vinda da sessao autenticada, nunca de parametro do cliente.
- No banco, com seguranca em nivel de linha.
- Chaves compostas com o tenant, tornando referencias cruzadas estruturalmente impossiveis.
Onde os vazamentos realmente ocorrem
- Relatorios e agregacoes escritos fora do caminho padrao.
- Exportacoes, sobretudo em processos de fundo.
- Busca global com motor separado.
- Arquivos de midia com links adivinhaveis ou sem checagem de propriedade.
- Jobs e filas que perdem a identidade do tenant.
- Webhooks de entrada, que devem mapear o tenant por dado verificado.
Testar isolamento de forma sistematica
- Testes de integracao com dois tenants.
- Testes negativos em cada endpoint.
- Checagens automaticas de codigo para consultas fora do padrao.
- Testes especificos de jobs de fundo.
Desempenho e operacao
- Indices comecando pela coluna de tenant.
- Atencao a clientes gigantes.
- Limites de taxa por tenant.
- Plano de exclusao e exportacao por tenant.
Perguntas frequentes
Banco separado e sempre mais seguro?
E mais facil de garantir, nao automaticamente mais seguro; disciplina decide.
Da para mudar de padrao depois?
Sim, com custo; sair de tabelas compartilhadas para bancos separados e mais facil que o inverso.
Proximo passo
Audite as areas de borda citadas: exportacao, busca, midia e jobs. Veja a pagina do produto.
