O que é arquitetura multi-tenant?

A multi-tenancy é o modelo que torna o software como serviço economicamente viável. Em vez de montar uma cópia separada da aplicação para cada cliente, uma única implantação atende a todos, e a separação entre eles é garantida por software. O caminho de atualização, o esforço operacional e o custo por cliente melhoram drasticamente. A contrapartida é que o isolamento passa a ser uma propriedade que você precisa construir e defender, e não algo que o hardware entrega de graça.

Para uma plataforma de contact center, o que está em jogo é especialmente alto, porque os dados envolvidos são gravações de chamadas, listas de contatos de clientes, registros de consentimento e listas de supressão. Um BPO que opera clientes concorrentes em uma mesma plataforma tem a obrigação contratual — e muitas vezes regulatória — de mantê-los separados, e um vazamento não é um inconveniente, é um incidente.

Onde o isolamento deve ser garantido

A implementação comum mais frágil coloca a fronteira no código da aplicação: cada consulta filtra por tenant, e a correção depende de todo desenvolvedor lembrar disso todas as vezes. Funciona até o dia em que uma consulta não filtra, e nada revela o erro até alguém ver dados que não deveria. A abordagem mais robusta leva a garantia para o banco de dados, de modo que a política fique vinculada aos dados, e não ao código que os lê, e uma consulta que omite o filtro de tenant não retorne nada, em vez de retornar tudo. Ao avaliar uma plataforma, a pergunta útil não é se os tenants são isolados, mas em qual camada.

O que precisa variar por tenant

• Dados e usuários. Campanhas, contatos, gravações e contas, com escopo definido para que um usuário só exista dentro do seu tenant.
• Configuração de conformidade. Listas de supressão, horários de ligação e regras de consentimento, já que os tenants operam sob regimes diferentes.
• Retenção. Retenção de gravações e transcrições conforme a política de cada tenant, com retenção legal (legal hold) disponível.
• Números. Identidade de chamador pertencente exclusivamente a um tenant e uma faixa de ramais que não colide com a de outro.
• Marca e idioma. A interface que os usuários de cada tenant veem, incluindo o idioma padrão.
• Faturamento e medição. Consumo atribuível a cada tenant, e não somado em um único total.

Como a DialerBee implementa multi-tenancy

O arquitetura multi-tenant oferece a cada tenant dados isolados, garantidos por segurança em nível de linha (row-level security) do PostgreSQL na camada do banco de dados; regras de conformidade independentes, que abrangem listas de "não ligar", horários de ligação e controle de consentimento; gravações de chamadas separadas, com armazenamento por tenant; retenção e retenção legal independentes; faturamento por tenant, com consumo, minutos e posições acompanhados separadamente; controle de acesso baseado em funções que restringe agentes e supervisores ao seu tenant; ajuste de IA por tenant; e provisionamento de tenants em minutos pelo portal de administração ou pela API. Está disponível em 11 idiomas, com idioma padrão por tenant.

A fronteira acompanha o restante da plataforma, em vez de parar no banco de dados. Todo dashboard e relatório em análises tem escopo no tenant atual, então os clientes de um BPO veem apenas os próprios dados, enquanto os donos da plataforma podem acessar análises entre tenants, e as fronteiras entre tenants são garantidas na camada do banco de dados. A propriedade de cada identificador de chamadas é exclusiva de um tenant, o que impede que um número pelo qual você responde apareça nas chamadas de outra empresa, e cada tenant tem seus próprios pools de identificadores de chamada, com regras de rotação e relatórios isolados. Os dados de transcrição são armazenados com isolamento por tenant usando segurança em nível de linha, com retenção configurável por tenant. Em implantações white-label , um administrador parceiro é dono dos tenants que cria, e o assistente de onboarding define a faixa de ramais e os identificadores de chamada próprios de cada tenant, porque os padrões colidem e um tronco compartilhado não é um identificador de chamada.

Perguntas frequentes

Qual a diferença entre multi-tenant e single-tenant?

Em uma implantação single-tenant, cada cliente tem sua própria instância do software e, muitas vezes, sua própria infraestrutura. Em uma implantação multi-tenant, os clientes compartilham a infraestrutura e o código e são separados pela aplicação e pelo banco de dados, e não por terem cópias separadas. O multi-tenant é mais barato de operar e de atualizar; o single-tenant oferece separação física a um custo por cliente muito maior.

O que é segurança em nível de linha?

Um recurso de banco de dados que vincula uma política a uma tabela, para que uma consulta só possa retornar as linhas que o tenant atual tem direito de ver. Isso importa porque a alternativa — filtrar por tenant em cada consulta que a aplicação faz — depende de todo desenvolvedor lembrar disso todas as vezes. Garantir isso na camada do banco de dados significa que uma consulta que esquece o filtro não retorna nada, em vez de retornar tudo.

Multi-tenancy significa que meus dados ficam misturados com os de outros clientes?

Significa que eles ficam armazenados em infraestrutura compartilhada, com fronteiras garantidas, e não que outra pessoa possa acessá-los. A pergunta prática a fazer a um fornecedor não é se as tabelas são compartilhadas, mas onde o isolamento é garantido. Isolamento implementado só no código da aplicação é uma resposta mais fraca do que isolamento garantido pelo banco de dados.

Por que cada tenant precisa da própria faixa de ramais e dos próprios identificadores de chamada?

Porque os padrões colidem. Dois tenants provisionados com a mesma faixa de ramais ou apontados para o mesmo tronco geram chamadas mal encaminhadas e uma identidade de chamador que pertence à empresa errada. Dar a cada tenant sua própria faixa e seus próprios números no provisionamento evita um tipo de problema desagradável de diagnosticar depois.

O que deve ser configurável por tenant?

Tudo o que difere entre as empresas que usam a plataforma — o que, em um contact center, é quase tudo: regras de conformidade, horários de ligação, listas de supressão, prazos de retenção, idioma padrão, marca, números e faturamento. Uma configuração que só pode ser global é uma configuração que, cedo ou tarde, estará errada para alguém.

Termos relacionados: plataforma de contact center white-label, contact center BPO, gestão de consentimento, identificador de chamadas e presença local e DID.