Entendendo na Prática: o que e Multitenancy

O que e multitenancy?

E a capacidade de um sistema servir múltiplos clientes usando a mesma infraestrutura compartilhada.

Multitenancy e o modelo arquitetural onde uma única instância de um sistema serve múltiplos clientes, chamados de tenants, ao mesmo tempo. Cada tenant ve apenas seus próprios dados, mas compartilha o mesmo software, o mesmo banco de dados e a mesma infraestrutura com todos os outros. E o modelo básico de qualquer SaaS: o Salesforce, o Slack e o GitHub usam multitenancy para atender milhares de empresas com um único sistema. O desafio central e garantir o isolamento de dados entre tenants sem a complexidade e o custo de manter instâncias separadas para cada cliente.

Single-tenant versus multi-tenant

A escolha entre os dois modelos define custo, complexidade e isolamento do produto.

No modelo single-tenant, cada cliente tem sua própria instância do sistema: servidor, banco de dados e aplicação dedicados. O isolamento e total, a customização e mais simples e um problema em um tenant não afeta os outros. O custo operacional, porém, cresce linearmente com o número de clientes. No modelo multi-tenant, todos os clientes compartilham a infraestrutura. O custo operacional cresce de forma muito mais lenta e o time de produto mantem apenas uma versão do sistema. A complexidade técnica, porém, e maior: o isolamento precisa ser garantido pelo código, não pela infraestrutura.

Estrategias de banco de dados para multitenancy

Shared database, schema por tenant ou database dedicado: cada opção tem tradeoffs claros.

Existem tres estrategias principais. Na shared database com shared schema, todos os tenants compartilham as mesmas tabelas e o isolamento e feito por uma coluna tenant_id em cada registro. E a opção mais econômica em recursos mas exige disciplina rigorosa para nunca vazar dados entre tenants. Na shared database com schema por tenant, cada tenant tem seu próprio schema dentro do mesmo banco, o que oferece isolamento maior sem duplicar servidores. No database por tenant, cada cliente tem seu próprio banco, o que oferece máximo isolamento e facilidade de backup individual, mas o custo de recursos cresce com o número de clientes.

Row-level security

Isolamento diretamente no banco de dados via políticas de segurança por linha.

Row-level security, disponível no PostgreSQL e em outros bancos, permite definir políticas no próprio banco que filtram automaticamente as linhas visíveis para cada conexão com base no contexto do tenant. Em vez de confiar que a aplicação sempre vai incluir o WHERE tenant_id = X nas queries, o próprio banco garante que nenhuma query retorna dados de outro tenant. Isso cria uma camada de segurança independente do código da aplicação. A configuração envolve criar políticas com CREATE POLICY e habilitar RLS na tabela. O contexto do tenant e passado via SET LOCAL ou via parametros de configuração da conexão.

Tenant context

O mecanismo que injeta o tenant_id automaticamente em todas as operações do sistema.

Para que a aplicação saiba qual tenant esta fazendo cada requisição, e necessário um mecanismo de tenant context. Geralmente implementado como um middleware no request pipeline, ele extrai o identificador do tenant do JWT, do subdominio ou de um header da requisição e o armazena em um contexto de execução (como AsyncLocal em .NET ou AsyncLocalStorage em Node.js). Repositories e services dao leem esse contexto e incluem o tenant_id automaticamente em todas as queries. Isso evita que cada metodo de negócio precise receber e repassar o tenant explicitamente, reduzindo o risco de esquecer o filtro em algum lugar.

Rate limiting e quotas por tenant

Controlar o consumo de cada cliente e essencial para proteger o sistema inteiro.

Em um sistema multi-tenant, um tenant que faz requisições excessivas pode degradar a experiência de todos os outros. Rate limiting por tenant limita o número de requisições por janela de tempo. Quotas controlam o consumo de recursos mais persistentes, como storage, número de usuários, número de registros ou uso de features específicas por plano. Implementar essas restrições no API gateway ou no middleware da aplicação protege o sistema e permite monetização por uso. Ferramentas como Redis facilitam a contagem de requisições distribuída sem estado compartilhado entre instâncias da aplicação.

Onboarding de novos tenants

O processo de adicionar um novo cliente deve ser automatizado e auditável.

Em um SaaS bem projetado, adicionar um novo tenant e uma operação automatizada: criar o registro do tenant no banco, provisionar o schema ou banco dedicado se necessário, criar o usuário administrador inicial, configurar limites e plano, e enviar o email de boas-vindas. Tudo isso deve ser feito por código, sem intervenção manual. A automação reduz erros, acelera o tempo de ativação e permite escalar para milhares de tenants. E importante que o processo de onboarding seja transacional ou pelo menos idempotente: se falhar no meio, deve ser possível tentar novamente sem deixar dados inconsistentes.

Exemplos com Salesforce e Slack

Os maiores SaaS do mundo são multi-tenant por definição.

O Salesforce serve mais de 150 mil empresas com a mesma plataforma. Cada organização e um tenant com seus próprios dados, customizações e usuários. O isolamento e garantido por uma camada de abstrato de dados chamada MTS (Multi-Tenant Storage) que adiciona automaticamente o identificador da organização em todas as queries. O Slack atende milhões de workspaces com um único sistema. Cada workspace e um tenant com seus próprios canais, mensagens e usuários. A arquitetura permite que o Slack escale a infraestrutura de forma proporcional ao uso, não ao número de clientes, o que torna o modelo economicamente vantajoso.

Quando escolher cada estrategia

A escolha depende do nível de isolamento exigido pelo cliente e do custo aceitável.

Use shared database com shared schema para produtos com muitos clientes pequenos, dados pouco sensíveis e onde o custo de infraestrutura precisa ser mínimo. Use schema por tenant quando clientes precisam de backups individuais, migração independente ou maior isolamento sem o custo de bancos separados. Use database por tenant para clientes enterprise que exigem isolamento total por compliance, para integração com sistemas legados por tenant ou quando cada cliente tem volumes de dados muito diferentes. E possível combinar as estrategias: clientes do plano básico em shared schema e clientes enterprise em banco dedicado.

Resumo

Multitenancy e o modelo que viabiliza SaaS escalável, bem implementado e invisível para o usuário.

Multitenancy e um dos pilares arquiteturais de qualquer SaaS. A escolha da estrategia de banco de dados, a implementação do tenant context, a aplicação de row-level security e o controle de quotas por tenant são decisões que impactam segurança, custo e escalabilidade do produto. Quando bem implementado, o usuário não sabe nem percebe que compartilha infraestrutura com outros clientes. Quando mal implementado, vazamentos de dados entre tenants são catastroficos. Investir em uma arquitetura multi-tenant solida desde o inicio evita reescritas custosas e constroi a base para crescer de dezenas para milhares de clientes.