Multi-tenancy explicado:uma base de dados, 1.000 clientes

Multi-tenancy explicado: multi-tenancy significa que vários clientes partilham uma base de dados, mas cada cliente só consegue ver os seus próprios dados. É assim que um fundador a solo serve 1.000 organizações a partir de uma única aplicação sem reconstruir nada — e funciona graças a uma coluna que tem de estar em todas as tabelas desde o primeiro dia: organization_id.

Se estás a construir um SaaS com IA, esta é uma das poucas decisões de arquitetura que não consegues corrigir barato mais tarde. Eis o que é o multi-tenancy, porque é que a escolha errada custa meses e as regras exatas que deves dar à tua IA para que acerte.

Multi-tenancy explicado: a analogia do prédio de apartamentos

Pensa no teu SaaS como um edifício. Cada cliente é um inquilino. Tens duas opções.

Podes construir uma casa separada para cada cliente. Cada casa precisa das suas próprias fundações, canalização e manutenção. Dez clientes, dez casas. Mil clientes, mil casas — e quando quiseres renovar a cozinha, renovas mil cozinhas.

Ou constróis um prédio de apartamentos. Umas fundações, uma canalização, uma equipa de manutenção. Cada inquilino tem o seu apartamento, a sua fechadura, a sua chave. Ninguém consegue entrar no apartamento do vizinho, mas só manténs um edifício.

O multi-tenancy é o prédio de apartamentos. Uma aplicação, uma base de dados, um deploy — a servir todos os clientes, cada um a ver apenas os seus próprios dados. É a arquitetura padrão de quase todos os produtos SaaS que usas, e é o que torna possível a economia de um SaaS à escala de uma só pessoa.

As três formas de servir 1.000 clientes

Tecnicamente, há três abordagens. Só uma delas faz sentido para um fundador a solo:

A terceira opção é aquela em que a indústria convergiu, e é dela que trata este artigo. Uma base de dados para manter. Uma alteração para correr quando melhoras alguma coisa. Uma cópia de segurança. E podes crescer de 1 para 10.000 clientes sem alterações ao esquema.

A coluna de que todas as tabelas precisam

Eis a regra de ouro: todas as tabelas que guardam dados de clientes têm de ter uma coluna organization_id. Não "deviam ter". Não "pode acrescentar-se depois". Têm de ter, desde o primeiro dia.

Não precisas de escrever código para perceber isto. Em termos conceptuais, cada linha da tua base de dados recebe uma etiqueta que diz a que cliente pertence. Na tabela de tarefas de um gestor de tarefas, "Desenhar a página inicial" leva a etiqueta da Acme; "Rever os números do 3.º trimestre" leva a da TechStart. Sempre que a aplicação lê dados, pede apenas as linhas com a etiqueta do cliente atual. Sempre que escreve dados, carimba a nova linha com essa etiqueta. A Acme vê as tarefas da Acme. A TechStart vê as da TechStart. A etiqueta é a chave do apartamento.

Parece aborrecido. Também é a base que faz tudo o resto funcionar — incluindo a camada de segurança que a impõe automaticamente ao nível da base de dados, que merece (e tem) o seu próprio artigo.

O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →

"Mas por agora só tenho um cliente"

Ouço isto constantemente. Eis o filme que se desenrola quando saltas o multi-tenancy:

• Dia 1: Constróis para um cliente. Tudo funciona. Não são precisas etiquetas — os dados são todos dele, de qualquer maneira.
• Dia 30: Consegues um segundo cliente. Agora os dois clientes veem os dados um do outro. Pânico. Acrescentar a etiqueta a todas as tabelas a posteriori significa cerca de três semanas de trabalho, tempo de indisponibilidade em produção e clientes irritados.
• O filme alternativo: constróis com organization_id desde o dia 1. No dia 30, o segundo cliente simplesmente funciona. No dia 300, tens 100 clientes e fizeste zero alterações à base de dados.

Um amigo meu construiu o seu SaaS sem multi-tenancy. Quando chegou ao 10.º cliente, passou três meses a reconstruir toda a base de dados. Três meses sem funcionalidades novas enquanto os clientes esperavam. Não sejas essa pessoa.

É também por isso que insisto tanto em desenhar a base de dados antes de escrever prompts: as decisões que são baratas no primeiro dia — uma coluna, um hábito — tornam-se brutalmente caras no dia 300.

As três regras que o mantêm rápido e seguro

Regra 1: etiqueta todas as tabelas, sem exceções. No momento em que falta organization_id a uma tabela, essa tabela é uma fuga de dados à espera de acontecer. Quando dás instruções à tua IA, torna isto uma instrução permanente, não um pedido tarefa a tarefa — é exatamente o tipo de regra que pertence às tuas decisões ao nível de arquiteto, porque a IA salta-a alegremente se não insistires.

Regra 2: cria um índice para a etiqueta. Um índice é a lista telefónica da base de dados — permite-lhe saltar diretamente para as linhas de um cliente em vez de ler todas as linhas para verificar a etiqueta. A diferença não é académica: com 1 milhão de linhas repartidas por 1.000 organizações, uma pesquisa sem índice demora cerca de 2.000 milissegundos. Com índice, a mesma pesquisa demora cerca de 5. Pede à tua IA que acrescente um índice em organization_id em todas as tabelas que criar.

Regra 3: nunca confies no browser para dizer quem está a perguntar. A identidade do cliente tem de vir da sessão iniciada no servidor, nunca de algo que o browser envia. Se um utilizador mal-intencionado conseguir dizer à tua aplicação "sou a organização X", consegue ler os dados da organização X. O servidor sabe quem tem sessão iniciada; essa é a única fonte de verdade.

Três regras. Uma coluna. É essa a diferença entre uma demonstração e um produto que consegues vender ao teu segundo, décimo e milésimo cliente.

12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →

Perguntas frequentes

O que significa multi-tenancy em termos simples?

Vários clientes (inquilinos) partilham uma aplicação e uma base de dados, mas cada um só consegue ver os seus próprios dados. Como um prédio de apartamentos: uma estrutura, muitos apartamentos privados, uma chave por inquilino. É a arquitetura padrão dos produtos SaaS.

Preciso de multi-tenancy se só tenho um cliente?

Sim — é precisamente quando é barato. Acrescentar uma coluna organization_id no primeiro dia não te custa nada. Acrescentá-la depois de chegar o segundo cliente custa semanas; um fundador que conheço passou três meses a reconstruir ao 10.º cliente. Integra-a desde a primeira tabela.

A IA consegue montar o multi-tenancy por mim se eu não souber programar?

Sim, se lhe deres a regra explicitamente: "todas as tabelas que guardam dados de clientes têm de ter uma coluna organization_id, com um índice, e todas as consultas têm de filtrar por ela." As ferramentas de IA seguem este padrão de forma fiável quando lhes dizem — e saltam-no de forma imprevisível quando não dizem. Tu dás a regra; a IA dá a implementação.

Uma base de dados partilhada é segura o suficiente para dados de clientes?

Sim, quando é bem feita. A etiqueta organization_id mais a segurança ao nível da base de dados (row-level security, que impõe a etiqueta automaticamente em cada consulta) é a forma como praticamente todo o SaaS moderno trata o isolamento — a mesma abordagem que serve produtos com milhares de organizações. A opção insegura é a versão feita a meio: base de dados partilhada, sem etiquetas, sem imposição.