Construindo um SaaS multi-tenant: o que considerar

As decisões multi-tenant que são baratas de acertar cedo e caras de mudar depois — isolamento de dados, cobrança e permissões.

Plataformas SaaS multi-tenant atendem muitos clientes (tenants) a partir de uma única base de código e infraestrutura — é isso que faz a economia do SaaS funcionar. Mas as decisões de arquitetura que fazem o multi-tenant funcionar bem são do tipo barato de acertar cedo e muito caro de corrigir depois.

A primeira decisão é a estratégia de isolamento de dados: um banco compartilhado com um ID de tenant em cada tabela é o mais simples e barato de operar, mas exige disciplina rígida — toda consulta precisa filtrar por tenant, ou você corre o risco de vazar dados de um cliente pra outro. Schemas ou bancos isolados por tenant dão garantias mais fortes e são mais fáceis de justificar pra clientes sensíveis a conformidade, mas custam mais em escala. A maioria dos produtos SaaS começa compartilhado e só migra tenants de alto valor pra infraestrutura isolada quando um contrato exige.

A segunda decisão são as permissões: papéis em nível de tenant precisam ser aplicados de forma consistente em cada endpoint de API, não só na interface, e precisam considerar que um usuário pode pertencer a múltiplos tenants (um caso comum pra agências e consultores que gerenciam várias contas). A terceira é cobrança: preço baseado em uso exige infraestrutura de medição desde o primeiro dia, porque adicionar rastreamento de uso preciso a um sistema que não foi desenhado pra isso é uma das migrações mais dolorosas que já vimos.

A quarta, muitas vezes subestimada, é onboarding: sistemas multi-tenant precisam de um fluxo self-service tranquilo pra criar um novo tenant, convidar membros do time e definir padrões, porque provisionar tenants manualmente não escala além da primeira dezena de clientes. Acertar essas quatro decisões desde o início é o que permite uma plataforma SaaS crescer de dez pra dez mil clientes sem reescrever tudo.