Multi-tenant é a arquitetura de software em que uma única instalação atende vários clientes ao mesmo tempo, cada um com seus próprios dados, usuários e configurações, separados dos demais. O nome vem de “tenant”, inquilino em inglês: todos moram no mesmo sistema, mas ninguém entra na casa do outro. Boa parte do software por assinatura que você usa, do e-mail ao CRM, funciona assim.
Para quem vai revender tecnologia com a própria marca, o conceito interessa por um motivo prático. É a arquitetura multi-tenant, com uma camada de parceiro por cima, que permite configurar marca, domínio, cobrança e módulos cliente por cliente sem montar uma instalação nova para cada um. Quando ela falta, o que sobra é logo trocado numa conta compartilhada, e isso não acompanha a carteira quando ela cresce.
Resumo: multi-tenant descreve como o software é construído (uma base compartilhada, clientes isolados); white label descreve como ele é vendido (com a marca de quem revende). São coisas diferentes e uma não implica a outra. Mas white label real depende de multi-tenant bem feito, porque os critérios que definem white label, como domínio próprio e cobrança no CNPJ da agência, precisam ser configurados por parceiro ou por cliente e ficar isolados entre eles.
O que é multi-tenant, sem jargão
Uma definição de referência vem do NIST, o instituto de padrões dos Estados Unidos. Na publicação SP 800-145, de 2011, que define computação em nuvem, o NIST descreve o agrupamento de recursos assim: os recursos do provedor atendem vários consumidores “usando um modelo multi-tenant”, com recursos físicos e virtuais distribuídos conforme a demanda. Traduzindo: servidor, banco de dados e código são compartilhados; o que cada cliente vê e mexe, não.
O “multi tenancy” que aparece em textos em inglês é o substantivo do mesmo conceito. Multi-tenant é o adjetivo (uma plataforma multi-tenant), multi-tenancy é a propriedade (a plataforma tem multi-tenancy). Em português os dois viraram sinônimos na prática.
O que torna uma plataforma multi-tenant, para quem usa, são três separações que você consegue testar: os dados de um cliente não aparecem para outro; cada cliente tem seus próprios usuários e permissões; e cada cliente tem configurações próprias (campos, funis, automações, marca) que não vazam para os vizinhos.
Como o isolamento funciona por baixo
Existem jeitos diferentes de separar inquilinos, e o fornecedor nem sempre conta qual usa. O guia de modelos de tenancy do Azure Architecture Center, da Microsoft, descreve um espectro com dois extremos e combinações no meio:
- Totalmente compartilhado. Uma aplicação e um banco para todos, com cada registro marcado pelo identificador do cliente. É o mais barato de operar e de atualizar. O risco, nas palavras do próprio guia, é vazar dados entre tenants se a separação falhar, e um cliente pesado afetar os outros.
- Particionado. Aplicação compartilhada, mas banco de dados separado por cliente, por exemplo. Isola mais os dados, custa mais e complica um pouco a manutenção.
- Single-tenant automatizado. Uma infraestrutura inteira por cliente, criada por automação. Isola tudo e custa caro: o guia observa que, se um tenant tem um custo de infraestrutura, cem tenants provavelmente custam cem vezes isso.
Para o consultor que avalia um fornecedor, o modelo exato importa menos que duas perguntas: como a separação entre clientes é garantida e testada, e o que acontece com os outros clientes quando um deles dispara uma campanha enorme ou importa uma base gigante. O segundo problema tem nome no meio técnico, “vizinho barulhento”, e aparece primeiro em plataformas que compartilham tudo sem limite por cliente.
Multi-tenant vs single-tenant: qual a diferença na prática?
Single-tenant é o oposto: cada cliente tem sua própria instalação do software. Faz sentido em contexto regulado ou com exigência contratual de infraestrutura dedicada. Para uma agência que quer revender para dezenas de pequenas e médias empresas, quase nunca faz.
| Critério | Multi-tenant | Single-tenant |
|---|---|---|
| Custo por cliente | Baixo, a infraestrutura é dividida | Alto, cresce junto com o número de clientes |
| Atualizações | Uma vez, para todos ao mesmo tempo | Instalação por instalação, versões podem divergir |
| Isolamento | Lógico, depende de a plataforma separar bem | Físico, por construção |
| Risco típico | Vazamento entre clientes ou vizinho barulhento | Instalação esquecida em versão antiga |
| Novo cliente | Criar um ambiente no painel | Provisionar infraestrutura |
A atualização única tem um lado ruim que pouca gente menciona: uma mudança errada atinge a base inteira de uma vez, risco que o guia da Microsoft também aponta. Para a agência, isso significa que a qualidade do processo de lançamento do fornecedor é parte do produto que ela revende. Vale perguntar como ele testa e libera versões.
Multi-tenant e white label são a mesma coisa?
Não. Multi-tenant é arquitetura; white label é modelo comercial e de marca. Os dois aparecem juntos com frequência, o que alimenta a confusão.
Existe multi-tenant sem white label: quase todo SaaS de prateleira é multi-tenant e mostra a própria marca para todo mundo. E existe “white label” sem multi-tenant de verdade. Os dois formatos mais comuns são o fornecedor que entrega uma instalação separada por revendedor, configurada à mão, e a conta única compartilhada onde a agência troca o logo e cria usuários para cada cliente lá dentro. O segundo é o caso perigoso: os clientes estão separados só por convenção, um usuário com permissão errada enxerga o funil do vizinho, e não há como ter domínio ou cobrança diferentes por cliente.
O que um white label precisa, além do multi-tenant comum, é uma camada acima dos clientes: o parceiro. A agência administra vários ambientes de clientes, cada um isolado dos outros, a partir de um painel dela, e o fornecedor fica fora da vista de todos. É multi-tenant em dois níveis.
Por que multi-tenant separa white label real de logo trocado
O guia de CRM white label define seis critérios cumulativos para white label real: marca 100% da agência em todas as interfaces que o cliente final toca, domínio próprio incluído, identidade visual customizada de verdade, cobrança no CNPJ da agência, split de receita automatizado e suporte exclusivo à agência, com o fornecedor invisível. Multi-tenant não está na lista. Mas olhe os critérios pelo ângulo da arquitetura e repare que quase todos são configurações que precisam existir por parceiro ou por cliente, sem vazar para os vizinhos.
Domínio próprio exige que a plataforma saiba qual parceiro responde em qual endereço. E-mail de convite com a marca certa exige modelo de e-mail por parceiro. Cobrança no CNPJ da agência, com valor diferente para cada cliente, exige cobrança ligada ao inquilino. Numa conta compartilhada com logo trocado, nada disso tem onde morar. Por isso, na nossa leitura, multi-tenant em dois níveis é a condição técnica que torna os seis critérios possíveis em escala. Sem ela, a agência até cumpre os critérios para um cliente, com trabalho manual, mas não consegue repetir isso para a carteira inteira.
Na Cubo Suite, cada cliente da agência tem um ambiente separado, com usuários, dados e permissões próprios, e a agência administra todos num painel de parceiro, liga e desliga módulos por cliente e pode aplicar a configuração de um cliente a outro. Se quiser ver isso funcionando, peça uma demonstração do painel de parceiro da Cubo Suite.
Cinco testes para fazer na demonstração
- Peça para criar dois clientes na sua frente. Entre com um usuário do cliente A e tente achar qualquer contato, negócio ou conversa do cliente B.
- Mude um campo personalizado ou uma etapa de funil no cliente A e confira se o cliente B continua igual.
- Pergunte se dá para copiar a configuração de um cliente para outro. Sem isso, cada cliente novo é implantação do zero.
- Confirme se domínio, cores e e-mails podem ser diferentes por cliente ou só por agência.
- Pergunte o que acontece com o desempenho dos outros clientes quando um deles faz disparo grande ou importa uma base pesada, e se existe limite por ambiente.
Se o vendedor não consegue fazer os testes 1 e 2 ao vivo, a separação entre clientes provavelmente existe só por convenção. Quando você estiver montando o restante da operação, o post sobre como montar um stack SaaS white label para agência mostra o custo de juntar várias ferramentas, cada uma com sua própria separação de clientes. O conceito geral do modelo está em o que é white label, e a parte de endereço e e-mail, em white label com domínio próprio.
Leve esses cinco testes para a demonstração do white label da Cubo Suite: a gente monta ambientes com a marca da sua agência, simula dois clientes da sua carteira e você confere a separação com os próprios olhos.
Perguntas frequentes
Multi tenant ou multi tenancy: qual o termo certo?
Os dois estão certos. Multi-tenant é o adjetivo (uma plataforma multi-tenant) e multi-tenancy é o substantivo (a característica de atender vários inquilinos numa só instalação). Em português técnico, os dois são usados como sinônimos.
O que é SaaS multi tenant?
É o software vendido como serviço em que todos os clientes usam a mesma instalação, com dados e configurações isolados. É o formato padrão do mercado de SaaS, porque divide o custo de infraestrutura e permite atualizar todos os clientes de uma vez.
Multi-tenant é seguro?
Depende de como a separação foi construída e testada. O risco próprio do modelo é o vazamento de dados entre clientes se a separação falhar. Na avaliação de um fornecedor, peça para ver dois clientes isolados ao vivo e pergunte onde ficam os servidores e como os dados são exportados.
Qual a diferença entre multi tenant e white label?
Multi-tenant é a arquitetura que atende vários clientes isolados numa só instalação; white label é o modelo em que alguém revende o software com a própria marca. Um SaaS comum é multi-tenant sem ser white label. Um white label real precisa de multi-tenant em dois níveis: a agência como parceira e cada cliente dela num ambiente isolado.
Deixe um comentário