O que é Hospedagem Multi-Tenant na Nuvem?

Hospedagem multi-tenant na nuvem é um modelo em que um conjunto de servidores e software atende muitos clientes, com isolamento lógico entre os tenants. Pense em um prédio de apartamentos: os moradores compartilham a estrutura, o encanamento e a rede elétrica, mas cada porta tem a sua fechadura. A alternativa — hospedagem single-tenant — é a casa própria: controle total, aluguel mais alto, e boa parte da manutenção fica com você.

Principais pontos

Como os dados dos tenants ficam separados

Todo sistema multi-tenant responde uma pergunta antes das outras: onde mora o isolamento? Na camada de banco há três padrões canônicos — schema compartilhado, schema por tenant e banco por tenant. O schema compartilhado é o cavalo de batalha, e fica mais seguro quando o próprio banco impõe a fronteira:

-- Padrão 1: schema compartilhado — cada linha carrega seu tenant
CREATE TABLE invoices (
  id        bigserial PRIMARY KEY,
  tenant_id uuid NOT NULL,
  amount    numeric(10,2) NOT NULL
);

-- Imponha o isolamento no banco, não em cada query
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

Com uma política de nível de linha, a query que esquece o filtro de tenant retorna nada em vez de tudo — o modo de falha vira página vazia em vez de vazamento de dados.

Em um Backend as a Service, o mesmo princípio se expressa como controle de acesso por objeto em vez de políticas SQL. Cada registro carrega uma ACL nomeando o role do tenant que pode vê-lo, e a plataforma a impõe em cada requisição:

// JavaScript / Node.js — Back4app JS SDK
const doc = new Parse.Object('Invoice');
doc.set('amount', 480);

const acl = new Parse.ACL();
acl.setPublicReadAccess(false); // invisible to every other tenant
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();

// Flutter / Dart — Back4app Flutter SDK
final doc = ParseObject('Invoice')..set('amount', 480);

final acl = ParseACL();
acl.setPublicReadAccess(allowed: false);
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();

// iOS / Swift — Back4app Swift SDK
var doc = Invoice()
doc.amount = 480

var acl = ParseACL()
acl.publicRead = false
acl.setReadAccess(roleName: "tenant-acme", value: true)
acl.setWriteAccess(roleName: "tenant-acme", value: true)
doc.ACL = acl
doc.save { _ in }

// Android / Kotlin — Back4app Android SDK
val doc = ParseObject("Invoice").apply { put("amount", 480) }

val acl = ParseACL().apply {
  publicReadAccess = false
  setRoleReadAccess("tenant-acme", true)
  setRoleWriteAccess("tenant-acme", true)
}
doc.acl = acl
doc.saveInBackground()

Isolamento é um espectro, não um interruptor

Entre “tudo compartilhado” e “tudo dedicado” ficam os três formatos de implantação entre os quais a maioria dos sistemas reais escolhe:

Plataformas maduras misturam os três: pool para os muitos tenants pequenos, bridge para os médios, e silo para os poucos que são regulados, enormes ou barulhentos. O erro é tratar a escolha como global — ela pode ser feita por plano, e até por componente.

Hospedagem multi-tenant vs. single-tenant

Dois sentidos que vale separar

“Hospedagem multi-tenant na nuvem” é usada em duas altitudes diferentes, e a maioria das explicações as embaralha:

• Como camada de hospedagem: hospedagem compartilhada — sua carga de trabalho roda nas mesmas máquinas físicas que as de outros clientes. É o modo padrão de toda nuvem pública; a definição do NIST lista o pooling de recursos entre tenants como característica essencial da própria computação em nuvem.
• Como arquitetura de aplicação: o seu produto atende os próprios clientes a partir de um backend compartilhado — o jeito como software por assinatura é construído. Aqui você é o senhorio, e o isolamento de tenants vira responsabilidade sua, que é onde entram os padrões acima.

Os dois sentidos se compõem: um produto SaaS (multi-tenancy no nível da aplicação) normalmente roda sobre infraestrutura de nuvem compartilhada (multi-tenancy no nível da hospedagem), cada camada isolando os próprios tenants.

O problema do vizinho barulhento

Compartilhar significa disputa: o import em massa de um tenant pode deixar lento o checkout de outro. As mitigações padrão, em ordem de escalada:

1. Quotas e rate limiting por tenant — limitar o que qualquer tenant pode consumir por janela.
2. Agendamento de recursos e autoscaling — absorver picos antes que virem a latência de outra pessoa.
3. Separação de cargas de trabalho — mover jobs pesados (exports, analytics) para filas em segundo plano, fora do caminho da requisição.
4. Silo parcial — quando um tenant roda quente de forma consistente, dar ao componente disputado (geralmente o banco) uma partição própria e manter o resto no pool.

Casos de uso comuns

• Produtos SaaS. Todo app por assinatura atendendo todos os clientes a partir de um codebase — o caso canônico, e a razão de o padrão existir.
• BaaS e hospedagem de plataforma. Plataformas rodam milhares de apps em infraestrutura compartilhada e isolada, então cada app custa quase zero para provisionar — o modelo por trás dos planos grátis.
• Aplicações B2B com workspaces por tenant. Uma implantação, muitas organizações clientes, cada uma com seus usuários, roles e fronteira de dados.
• Plataformas internas. Uma implantação de analytics ou ferramentas compartilhada entre departamentos, isolada por time.
• Agências rodando muitos apps de clientes. Plataforma compartilhada por baixo, um backend isolado por cliente em cima.

Multi-tenant, single-tenant ou misto? Matriz de decisão

O padrão é começar multi-tenant e sair dele tenant a tenant, por mérito — encaixar tenancy depois em um codebase single-tenant é muito mais difícil do que mover um cliente quente para um silo mais tarde.

Limitações e trade-offs

• O isolamento vale o que vale a sua imposição. Um filtro de tenant esquecido no código da aplicação é o vazamento cross-tenant clássico. Empurre a fronteira para a camada de dados — políticas de nível de linha, ACLs por objeto — para que a plataforma falhe fechada.
• Raio de dano compartilhado. Uma queda, um deploy ruim ou uma invasão podem afetar todos os tenants de uma vez. Rollouts em estágios e backups por tenant encolhem o dano, não o compartilhamento.
• Vizinhos barulhentos são estruturais. Quotas e agendamento administram a disputa; só o silo parcial a remove, a preços de silo parcial.
• Teto de customização. Os tenants compartilham um codebase, então comportamento por tenant vive em configuração e feature flags — uma restrição que clientes single-tenant não têm.
• Contexto de tenant em todo lugar. Cada query, chave de cache, job e linha de log precisa conhecer o tenant; a complexidade migra da infraestrutura para a aplicação — exatamente o fardo que o isolamento gerenciado na camada de dados existe para absorver.

Hospedagem multi-tenant no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Ele é multi-tenant nas duas altitudes. Como plataforma, roda milhares de backends de app isolados sobre infraestrutura compartilhada — e é por isso que um backend novo provisiona em minutos no plano grátis. Para os tenants da sua aplicação, o isolamento é um recurso da camada de dados, não uma convenção: cada objeto carrega uma ACL, roles agrupam usuários por tenant, e permissões em nível de classe definem regras para o schema inteiro, tudo imposto pelo Back4app em cada requisição. O mergulho de engenharia em row-level security mostra o padrão completo em um banco de documentos — sem depender de disciplina de WHERE.