Arquitetura multi-tenant: um SaaS para muitos clientes

Quando um produto SaaS cresce, mais cedo ou mais tarde surge uma decisão estrutural: montamos uma instalação separada para cada cliente ou partilhamos uma mesma plataforma entre todos? A arquitetura multi-tenant responde a essa pergunta permitindo que um único sistema atenda a muitos clientes —os tenants— enquanto cada um percebe o seu espaço como próprio e isolado. É o modelo que sustenta a maior parte do software de subscrição moderno, e compreendê-lo bem evita tanto o sobrecusto de duplicar infraestrutura como o risco de misturar dados alheios.

O que significa multi-tenant

Um tenant é cada cliente ou organização que usa o produto. Numa arquitetura multi-tenant, esse conjunto de clientes partilha a mesma aplicação e, habitualmente, a mesma base de dados, enquanto uma camada de isolamento garante que ninguém vê informação que não lhe pertence. Face ao modelo single-tenant —uma instância dedicada por cliente— a abordagem partilhada reduz drasticamente a superfície a operar e atualizar.

O isolamento pode ser conseguido de várias formas, e vale a pena conhecê-las porque condicionam o resto das decisões:

• Base de dados partilhada com coluna de tenant: todas as tabelas incluem um identificador de cliente e cada consulta filtra por ele. A opção mais eficiente em custo e a mais exigente em disciplina.
• Esquema por tenant: a mesma base de dados, mas cada cliente tem o seu próprio esquema. Mais isolamento, um pouco mais de gestão.
• Base de dados por tenant: separação forte, útil para clientes com requisitos regulatórios rigorosos, ao preço de mais infraestrutura para manter.

Vantagens de custo e manutenção

A razão pela qual este modelo domina é simples: opera-se um só sistema em vez de centenas. Isso tem consequências diretas.

• Um deployment, todos atualizados: uma correção ou uma nova funcionalidade chega a todos os clientes ao mesmo tempo, sem campanhas de atualização cliente a cliente.
• Melhor uso dos recursos: a capacidade é partilhada, de modo que os picos de uns se compensam com a calma de outros em vez de sobredimensionar em separado.
• Onboarding rápido: dar entrada a um cliente novo é criar um registo, não aprovisionar uma instalação completa.
• Observabilidade unificada: métricas, logs e alertas vivem num só lugar, o que facilita detetar problemas antes de se agravarem.

Essa poupança não é gratuita: paga-se com uma engenharia mais cuidada. O custo passa do hardware para o desenho.

O desafio real: isolamento e segurança

Partilhar plataforma significa que uma falha de isolamento não afeta um cliente, mas potencialmente todos. Por isso a segurança deixa de ser uma camada e passa a ser um princípio transversal.

Em multi-tenant, o isolamento não é uma funcionalidade que se testa uma vez: é uma propriedade que se defende em cada consulta, cada endpoint e cada tarefa em segundo plano.

Os pontos onde o rigor mais importa:

• Filtragem por tenant na origem: o identificador de cliente deve ser imposto na camada de acesso a dados, não confiado à memória de cada consulta. Um único WHERE esquecido é uma fuga.
• Autorização coerente: autenticar quem você é não basta; cada pedido deve verificar que o utilizador pertence ao tenant cujos dados solicita.
• Isolamento em tudo o que é assíncrono: filas, tarefas agendadas, caches e exportações também devem respeitar a fronteira do tenant, não apenas os pedidos web.
• Vizinhos barulhentos: um cliente muito ativo não deveria degradar o serviço dos restantes; são precisos limites e quotas.

Testes que presumem má intenção

A forma mais fiável de sustentar o isolamento é tratá-lo como algo que se verifica de forma automática e sistemática: testes que tentam, deliberadamente, aceder a dados de outro tenant e que devem falhar sempre. Se essa verificação não estiver automatizada, o isolamento depende da memória de quem programa, e isso não escala.

Quando faz sentido (e quando não)

O multi-tenant brilha quando se oferece o mesmo produto a muitos clientes com necessidades parecidas e se quer iterar depressa sobre uma base comum. É o terreno natural de um CMS de conteúdos ou de um ecommerce SaaS, onde o valor está em melhorar uma plataforma que todos partilham.

Há casos, porém, onde convém inclinar-se para um isolamento mais forte ou até dedicado: requisitos regulatórios que exigem separação física de dados, clientes com personalizações tão profundas que deixam de partilhar produto, ou acordos de desempenho que não toleram vizinhança alguma. Muitas plataformas maduras acabam num modelo híbrido: multi-tenant por omissão e isolamento reforçado para os poucos casos que o justificam.

Como o abordamos na InAI

Na InAI construímos produto com esta arquitetura como base. Tanto o nosso ecommerce SaaS como o CMS de conteúdos com IA nascem multi-tenant, com o isolamento por cliente entendido como uma regra defendida na camada de dados e verificada de forma automática, não como uma promessa. O objetivo é simples e pouco glamoroso: que cada cliente desfrute de uma plataforma que melhora para todos sem que a sua informação se cruze alguma vez com a de ninguém.

Não é magia nem uma etiqueta de marketing. É uma decisão de engenharia com vantagens claras e custos reais, e a chave está em assumir esses custos com honestidade desde o primeiro dia.