Multi-Tenancy em SaaS

Multi-tenancy existe em um espectro. Banco de dados compartilhado, esquema compartilhado: todos os dados dos inquilinos residem nas mesmas tabelas, diferenciados apenas por uma coluna tenant_id. Menor custo e arquitetura mais simples, mas cria o maior risco de vazamento de dados se a filtragem por tenant_id for omitida em qualquer consulta. Banco de dados compartilhado, esquemas separados: cada inquilino obtém seu próprio esquema dentro do banco de dados compartilhado. Isolamento ligeiramente melhor com custo de infraestrutura reduzido em comparação com a separação total. Bancos de dados separados por inquilino: os dados de cada cliente residem em um banco de dados completamente isolado. Maior garantia de isolamento, história de conformidade mais simples, mas custo de infraestrutura e complexidade operacional significativamente maiores (migrações de banco de dados devem ser executadas em N bancos de dados). A maioria das empresas SaaS começa com esquema compartilhado para eficiência de custos e migra para maior isolamento para segmentos empresariais que exigem residência de dados ou controles de conformidade mais rigorosos.

Multi-tenancy cria desafios específicos de solução de problemas para equipes de suporte. Bugs específicos do inquilino: um problema que afeta apenas o Inquilino A (mas não o Inquilino B, apesar de ambos usarem a mesma versão de código) é tipicamente causado por: estado de dados ou configuração específica do Inquilino A, um feature flag habilitado apenas para o Inquilino A, ou um limite de taxa sendo atingido apenas pelo padrão de uso do Inquilino A. Os agentes de suporte devem sempre restringir a investigação ao inquilino específico: "Isso se reproduz para este cliente específico, ou se reproduz para todos os clientes?" Um bug que é universalmente reproduzível é um bug de produto; um bug que é específico do inquilino é um problema de configuração ou um problema de integridade de dados. O suporte deve evitar corrigir os dados de um inquilino de uma forma que possa corromper os dados de outro inquilino ou violar as garantias de isolamento da arquitetura.

Multi-tenancy cria um risco operacional de "vizinho barulhento": o alto consumo de recursos de um inquilino pode degradar o desempenho para outros inquilinos que compartilham a mesma infraestrutura. Product Ops compartilha a responsabilidade pela estratégia de monitoramento e alerta com a Engenharia: painéis de consumo de recursos por inquilino identificam inquilinos que se aproximam dos limites de recursos antes que afetem outros. Limitação de taxa (rate limiting) e cotas de recursos por inquilino são as principais mitigações (limites de taxa evitam o uso excessivo da API; timeouts de consulta de banco de dados evitam que consultas de longa duração monopolizem os recursos compartilhados do banco de dados). Para clientes empresariais, Product Ops deve entender quais garantias de isolamento a arquitetura pode oferecer para fins de conformidade — as equipes de vendas e suporte precisam de respostas precisas para perguntas como "meus dados estão isolados de outros clientes?" em conversas de aquisição. Quando a arquitetura não pode fornecer o isolamento necessário, o nível empresarial pode exigir uma opção de implantação de inquilino único ou privada.