Arquitetura multi-inquilino, explicada sem jargão: um guia para fundadores

A certa altura, ao construir um produto de software, um programador dir-lhe-á a palavra "multi-inquilino", observará a sua cara e presumirá que percebeu. Provavelmente acenou com a cabeça. A maioria dos fundadores acena. Mas esta é uma daquelas decisões iniciais que, em silêncio, fixa o tecto: a rapidez com que pode crescer, o custo a que pode operar e a gravidade com que as coisas podem correr mal se um cliente alguma vez vir dados que não são seus. Vale dez minutos da sua atenção agora, porque voltar a este ponto mais tarde sai muito caro.

Já me sentei à frente de muitos fundadores sem perfil técnico — pessoas com uma ideia afiada de produto SaaS e sem especial interesse por bases de dados. A boa notícia é que não precisa de aprender a programar para tomar bem esta decisão. Precisa de um modelo mental claro e de uma lista curta de perguntas. É exatamente isto, este guia. Sem palavras da moda, sem diagramas de arquitetura que nunca mais vai olhar, apenas aquilo que o seu programador gostaria que percebesse antes da primeira linha de código.

Se levar daqui apenas uma ideia, que seja esta: a multitenancy não é uma funcionalidade que se acrescenta depois. É uma fundação. Uma casa pode-se repintar, mas não é fácil mudar aquilo sobre o qual assenta depois de as paredes estarem levantadas.

O que "multi-inquilino" significa realmente

Imagine um prédio de apartamentos. Cada inquilino tem o seu próprio apartamento — a sua chave, a sua mobília, a sua porta. Mas todos partilham a mesma estrutura: as fundações, as canalizações, o telhado, o elevador. O senhorio mantém um edifício, não cinquenta casas separadas, e é isso que torna a renda acessível. O software multi-inquilino funciona exatamente assim. Uma só aplicação serve muitos clientes — "inquilinos" — e cada um vive-a como o seu espaço privado, embora todos corram sobre o mesmo sistema partilhado por baixo.

A abordagem oposta é o single-tenant: cada cliente recebe a sua própria cópia separada do software, como construir uma moradia nova para cada um. Mais privado, mais personalizável — e drasticamente mais caro de construir, operar e atualizar, porque agora mantém cinquenta casas em vez de um edifício.

Quase todos os produtos que usa no dia a dia são multi-inquilino. O seu e-mail, a sua ferramenta de contabilidade, o seu sistema de marcações, o CRM onde vive a sua equipa de vendas. Você e mil outras empresas partilham o mesmo software subjacente, e nenhum de vós vê alguma vez os outros. Essa invisibilidade — essa separação limpa — é toda a arte da multitenancy.

Porque esta decisão toca todo o seu negócio

É tentador arquivar isto como "pormenor técnico de que o meu programador trata". Mas o modelo que escolhe repercute-se diretamente nas partes do negócio com que de facto se importa: a sua fatura mensal de alojamento, a rapidez com que consegue entregar uma nova funcionalidade a todos, o que pode prometer a um comprador empresarial nervoso e o estrago que um único erro pode causar.

Quando corrige um erro ou publica uma funcionalidade num produto multi-inquilino bem construído, todos os clientes a recebem de uma vez, a partir de uma única atualização. Num mundo single-tenant, teria de implementar essa alteração em cinquenta instalações separadas, cada uma talvez já um pouco diferente. Uma é uma terça-feira à tarde. A outra é um projeto. Multiplique isto ao longo de anos de atualizações e perceberá porque a indústria SaaS assenta na multitenancy.

O reverso é que partilhar infraestrutura aumenta o que está em jogo na separação. Num prédio, uma avaria de canalização pode afetar mais do que um apartamento. No software multi-inquilino, um erro na forma como mantém os inquilinos separados não incomoda apenas um cliente — pode expor os dados de toda a gente de uma vez. Isto não é razão para evitar a multitenancy. É a razão para a construir como deve ser, com alguém que já o fez antes.

As três formas de manter os inquilinos separados

Quando os programadores discutem multitenancy, costumam discutir quão separados devem estar os dados de cada inquilino. Há três abordagens comuns, e situam-se numa escala deslizante que vai de "máxima partilha, custo mínimo" a "máxima separação, custo máximo". Não tem de escolher uma você mesmo — mas deve perceber o compromisso que o seu programador está a assumir em seu nome.

1. Base de dados partilhada, tabelas partilhadas

Os dados de todos vivem na mesma base de dados, nas mesmas tabelas, com um rótulo escondido — um "ID de inquilino" — que marca que linhas pertencem a quem. O software é responsável por filtrar sempre por esse rótulo, para que o cliente A só veja as linhas do cliente A. É o modelo mais barato e mais escalável, o que a maioria dos produtos SaaS iniciais usa. O senão: a separação vive no código, por isso um único filtro esquecido é a forma como os dados se escapam. Exige uma engenharia cuidada e disciplinada.

2. Base de dados partilhada, compartimentos separados

Uma base de dados, mas cada inquilino recebe lá dentro a sua própria secção isolada (os programadores chamam-lhes "esquemas"). Separação mais forte do que no primeiro modelo, ainda razoavelmente eficiente, e mais fácil para, por exemplo, exportar ou apagar de forma limpa os dados de um cliente. O compromisso é mais peças em movimento para gerir à medida que cresce para as centenas e milhares de inquilinos.

3. Uma base de dados separada por inquilino

Cada cliente recebe a sua própria base de dados dedicada — o mais próximo de lhe dar uma casa privada continuando a partilhar a aplicação. É o isolamento mais forte e a história mais fácil de contar a um comprador empresarial preocupado com segurança. É também o mais caro de operar e gerir, pelo que tende a ficar reservado a clientes de alto valor, setores regulados ou produtos em que uma troca de dados seria catastrófica.

A parte em que não pode falhar: o isolamento

Se há um sítio onde gastar a sua preocupação, é aqui. O isolamento de inquilinos é a garantia de que o cliente A nunca pode, em circunstância alguma, ver, editar ou sequer intuir a existência dos dados do cliente B. Parece óbvio. É também a fonte isolada mais comum de erros graves em produtos multi-inquilino, porque a falha é silenciosa — está tudo a parecer bem até ao dia em que alguém abre um relatório e vê lá dentro os clientes de um desconhecido.

A razão por que isto acontece é estrutural. No modelo mais barato, cada pedido à base de dados tem de se lembrar de filtrar por inquilino. Faça-o bem dez mil vezes e mal uma só, e tem uma fuga. É por isso que as equipas experientes não dependem da memória dos programadores — incorporam o isolamento na fundação, de modo que esquecer se torne impossível em vez de apenas improvável. Não precisa de perceber como o fazem. Precisa de perguntar se o fazem.

Há também um primo mais discreto deste problema: o "vizinho barulhento". Como os inquilinos partilham a infraestrutura, um cliente a fazer algo pesado — uma importação gigante, um relatório descontrolado — pode tornar o sistema lento para todos os outros, do mesmo modo que um apartamento com todas as torneiras abertas pode baixar a pressão da água em todo o edifício. Um bom desenho multi-inquilino prevê isto com limites e partilha justa. Vale a pena perguntar, sobretudo se espera alguns clientes muito grandes.

Quando o single-tenant é mesmo a escolha certa

A multitenancy é a opção por omissão para SaaS, mas não é uma religião. Há razões honestas para dar a um cliente a sua própria cópia separada, e um bom consultor dir-lhe-á quando encontrou uma delas, em vez de forçar tudo no modelo partilhado.

• Um cliente de um setor regulado — saúde, finanças, administração pública — cujas regras de conformidade exigem, na prática, que os seus dados residam num lugar comprovadamente separado.
• Um único grande cliente que paga o suficiente para que uma configuração dedicada compense, e que pretende uma personalização profunda que não quer ver transbordar para a experiência de todos os outros.
• Dados tão sensíveis que o custo de uma fuga entre inquilinos poria fim ao negócio, tornando o isolamento máximo digno da despesa adicional.
• Um requisito on-premise, em que o software tem de correr dentro das próprias paredes do cliente em vez da sua cloud.

Repare no padrão: o single-tenant é a exceção a que recorre de forma deliberada, normalmente para um cliente específico de alto valor, não a opção por omissão sobre a qual constrói todo o negócio. Se um programador propuser single-tenant para o seu produto padrão logo no primeiro dia, peça-lhe que lhe explique porquê — costuma significar um custo de operação muito mais alto e atualizações mais lentas, e quer que isso seja uma escolha, não um acidente.

As perguntas a fazer antes de alguém escrever código

Não precisa de desenhar a arquitetura. Precisa de garantir que quem o faz pensou nas coisas certas. Eis a lista curta que gostaria que um fundador sem perfil técnico levasse a essa primeira conversa — imprima-a, faça-a, observe com que confiança lhe respondem.

1. 1
   Como vão manter os dados dos inquilinos separados?

   Está atento a uma resposta estrutural — o sistema impõe-no — e não a "vamos ter cuidado". Esta é a inegociável.
2. 2
   Que modelo estamos a usar, e porquê?

   Tabelas partilhadas, compartimentos separados ou base de dados por inquilino. Não há resposta errada, mas deve haver uma razão que se ajuste aos seus clientes e ao seu orçamento.
3. 3
   Poderemos oferecer isolamento dedicado a um grande cliente mais tarde?

   Mesmo que comece totalmente partilhado, o desenho deve deixar margem para dar a um cliente grande ou regulado uma separação mais forte sem uma reconstrução.
4. 4
   O que acontece quando um cliente se torna enorme?

   Como é que o sistema impede que um inquilino pesado deixe todos os outros lentos? Quer ouvir que os cenários de vizinho barulhento foram considerados.
5. 5
   Como exportamos ou apagamos de forma limpa os dados de um cliente?

   Os clientes vão-se embora, e a lei de proteção de dados exige que remova os seus dados a pedido. Isto deve ser uma operação simples e bem compreendida, não um pânico.

Não está a avaliar o pormenor técnico das respostas. Está a verificar que nenhuma destas perguntas cai como uma surpresa. Uma equipa que já construiu software multi-inquilino terá respostas nítidas, quase aborrecidas, às cinco. Uma hesitação na primeira ou na terceira é o sinal para abrandar e aprofundar.

Um exemplo curto, inspirado na realidade

Um fundador veio ter connosco com um protótipo funcional de uma ferramenta de marcações pensada para pequenas clínicas. Já tinha três clientes pagantes — e um problema silencioso. Para chegar depressa ao mercado, o primeiro programador tinha dado a cada clínica a sua própria cópia separada da aplicação. Três clientes, três instalações, três versões ligeiramente diferentes, porque cada uma tinha pedido um pequeno ajuste pelo caminho.

Com três, funcionava lindamente. O pesadelo do fundador era o pensamento de trinta. Cada correção de erro significava entrar em três sítios. Cada nova funcionalidade significava três implementações e três coisas para testar. Pôr uma clínica nova a funcionar levava quase uma semana à mão. O modelo que os tinha levado ao lançamento era agora o que limitava o seu crescimento — exatamente o problema de fundação de que trata todo este artigo.

Não arrancámos tudo numa reescrita dramática. Reconstruímos o núcleo sobre uma fundação multi-inquilino partilhada, com o isolamento imposto ao nível do sistema, mantivemos as personalizações por clínica como definições configuráveis em vez de bases de código separadas e migrámos as três clínicas existentes uma de cada vez, em paralelo, para que ninguém tivesse um dia de transição assustador. Pôr uma clínica nova a funcionar passou de uma semana de trabalho manual para um registo self-service. As novas funcionalidades chegam agora a cada cliente a partir de um único lançamento.

Os números aqui são ilustrativos, não uma promessa — cada produto é diferente —, mas a forma é típica: a reconstrução custou dinheiro a sério e uns dois meses, e pagou-se já com o primeiro punhado de novos clientes que de repente conseguiram integrar sem mexer um dedo. A lição que o fundador levou foi a mais barata: se tivessem feito as cinco perguntas no início, não teria havido nada para reconstruir.

Perguntas frequentes