Arquitetura Multi-Tenant vs Multi-Site: Como Decidir
Multi-Tenant vs Multi-Site: How to Decide
Vi teams passarem meses debatendo arquitetura multi-tenant vs multi-site, apenas para escolher a errada e gastar mais seis meses migrando. É uma daquelas decisões que parecem abstratas até você estar a três sprints de distância e perceber que seus editores de conteúdo podem acidentalmente publicar para a marca errada, ou seu pipeline de deployment leva 45 minutos porque está reconstruindo doze sites quando apenas um mudou.
Isso não é uma comparação teórica. Construí ambos os padrões -- às vezes para o mesmo cliente quando a primeira escolha não funcionou. Deixa eu te mostrar o que realmente importa na hora de tomar essa decisão.
Índice
- Definindo os Termos com Clareza
- Quando Arquitetura Multi-Tenant Vence
- Quando Arquitetura Multi-Site Vence
- O Framework de Decisão
- Padrões de Arquitetura na Prática
- Considerações de CMS
- Performance e Escalabilidade
- Análise de Custos
- Estratégias de Migração
- FAQ
Definindo os Termos com Clareza
Esses termos são usados de forma imprecisa, então vamos defini-los bem.
Arquitetura Multi-Tenant
Uma instância de aplicação serve múltiplos tenants (marcas, clientes, regiões). Eles compartilham o mesmo codebase, o mesmo banco de dados (geralmente), e o mesmo deployment. O isolamento de tenant acontece na camada de aplicação -- através de middleware, esquemas de banco de dados, ou filtragem em nível de linha.
Pense nisso como um prédio de apartamentos. Todos compartilham a estrutura, encanamento e eletricidade. Mas cada unidade tem sua própria fechadura.
Arquitetura Multi-Site
Cada site é uma instância de aplicação separada com seu próprio codebase (ou um fork de um compartilhado), seu próprio banco de dados, e seu próprio pipeline de deployment. Eles podem compartilhar um design system ou biblioteca de componentes, mas são deployados e operados independentemente.
Isso é mais como um loteamento. Mesmo construtor, plantas similares, mas cada casa fica em sua própria fundação.
A Zona Híbrida
Honestamente, a maioria dos sistemas em produção fica em algum lugar no meio. Você pode ter um CMS multi-tenant alimentando conteúdo para frontends deployados independentemente. Ou um codebase compartilhado que é deployado como instâncias separadas por tenant. A pergunta real não é "qual um" mas "onde no espectro".
Quando Arquitetura Multi-Tenant Vence
Multi-tenant brilha quando seus sites são mais parecidos do que diferentes.
Requisitos Fortes de Consistência de Marca
Se você está gerenciando 15 sites regionais para a mesma marca e o design precisa ficar bloqueado, multi-tenant é seu amigo. Um codebase significa uma única fonte de verdade para componentes, layouts e padrões de interação. Quando o time de brand atualiza os estilos de botão, isso sai para todos os sites.
Escalabilidade Rápida para Novos Tenants
Trabalhei com uma plataforma de franquia que precisava spinup de novos locais semanalmente. Com multi-tenant, adicionar um novo site era uma entrada de banco de dados e um registro de DNS. Sem nova infraestrutura, sem novos deployments. Tempo de lançamento saiu de duas semanas para uns 30 minutos.
Operações de Conteúdo Centralizadas
Quando você tem um pequeno time de conteúdo gerenciando múltiplas propriedades, multi-tenant mantém tudo em um só lugar. Editores fazem login em um sistema, trocam contextos, e gerenciam conteúdo em todos os tenants. Sem ter que lidar com credenciais para uma dúzia de instâncias de CMS.
Desenvolvimento de Features Compartilhadas
Toda feature que você constrói beneficia todos os tenants simultaneamente. Correções de bugs, melhorias de performance, novas integrações -- deploy uma vez, beneficia em todos os lugares. O ROI em esforço de desenvolvimento é multiplicativo.
Quando Arquitetura Multi-Site Vence
Multi-site vence quando seus sites precisam divergir significativamente.
Experiências de Usuário Radicalmente Diferentes
Se marca A é uma loja de e-commerce e marca B é uma publicação de conteúdo, colocar as duas em um codebase cria uma bagunça. Vi codebases multi-tenant onde 60% do código estava atrás de condicionais específicos de tenant. Nesse ponto, você não tem uma aplicação -- você tem várias ruins compartilhando um repo.
Requisitos de Tecnologia Diferentes
Talvez um site precise de Next.js para sua experiência dinâmica e tipo app, enquanto outro é um site pesado em conteúdo que é perfeito para Astro. Multi-site permite que cada propriedade use a ferramenta certa. Construímos portfólios onde alguns sites rodam em Next.js e outros em Astro, todos puxando de um CMS headless compartilhado.
Ciclos de Release Independentes
Quando diferentes unidades de negócio possuem diferentes sites e eles precisam fazer ship em seus próprios cronogramas, multi-tenant cria um gargalo. Um deployment para a nova feature do tenant A não deveria requerer testes de regressão do tenant B através do tenant Z. Multi-site dá a cada time autonomia.
Isolamento Regulatório ou de Dados
Alguns setores requerem isolamento duro de dados -- não apenas separação na camada de aplicação, mas fisicamente bancos de dados separados, potencialmente em regiões diferentes. Projetos de saúde, finanças e governo frequentemente exigem isso. Multi-site torna a conformidade simples porque o isolamento é arquitetural, não apenas lógico.
Diferentes Perfis de Performance
Se um tenant recebe 10M visitas mensais e outro recebe 50K, compartilhar infraestrutura significa que você está sobre-provisionando para o tenant pequeno ou sub-provisionando para o grande. Deployments separados deixam você dimensionar corretamente cada propriedade.
O Framework de Decisão
Aqui está o framework que realmente uso com clientes. Ponha uma nota em cada fator para sua situação:
| Fator | Favorece Multi-Tenant | Favorece Multi-Site |
|---|---|---|
| Similaridade de site | 80%+ UI/features compartilhadas | Menos que 50% compartilhado |
| Número de propriedades | 10+ sites | Menos que 5 sites |
| Taxa de crescimento | Adicionando sites frequentemente | Estável, raramente adicionando |
| Estrutura de time | Um time central | Times independentes por site |
| Modelo de conteúdo | Idêntico ou quase-idêntico | Significativamente diferente |
| Necessidades de conformidade | Requisitos padrão | Isolamento de dados rigoroso |
| Tech stack | Mesmo framework em todos os lugares | Diferentes frameworks necessários |
| Cadência de release | Releases coordenadas OK | Releases independentes requerido |
| Profundidade de customização | Nível de tema (cores, logos) | Estrutural (layouts, features) |
| Orçamento | Otimizar para eficiência | Otimizar para flexibilidade |
Se você está marcando principalmente em uma coluna, a decisão é clara. Se está dividido no meio, você provavelmente está procurando por uma abordagem híbrida -- e tudo bem.
Padrões de Arquitetura na Prática
Deixa eu ser concreto sobre como esses parecem em código.
Multi-Tenant com Next.js
O padrão mais comum que uso é resolução de tenant baseada em middleware:
// middleware.ts
import { NextRequest, NextResponse } from 'next/server';
const TENANT_MAP: Record<string, string> = {
'brand-a.com': 'brand-a',
'brand-b.com': 'brand-b',
'brand-c.com': 'brand-c',
};
export function middleware(request: NextRequest) {
const hostname = request.headers.get('host') || '';
const tenantId = TENANT_MAP[hostname] || 'default';
// Pass tenant context via headers
const response = NextResponse.next();
response.headers.set('x-tenant-id', tenantId);
// Rewrite to tenant-specific paths if needed
const url = request.nextUrl.clone();
url.pathname = `/${tenantId}${url.pathname}`;
return NextResponse.rewrite(url);
}
Então seus page components puxam configuração específica de tenant:
// lib/tenant-config.ts
export async function getTenantConfig(tenantId: string) {
// Could be from database, CMS, or config files
return {
theme: await fetchTheme(tenantId),
navigation: await fetchNavigation(tenantId),
features: await fetchFeatureFlags(tenantId),
locale: await fetchLocaleConfig(tenantId),
};
}
Isso funciona bem até seus tenants começarem a precisar de estruturas de página diferentes, estratégias de busca de dados diferentes, ou diferentes integrações de terceiros. É quando a lógica condicional começa a se acumular.
Multi-Site com Packages Compartilhados
Para multi-site, uso um monorepo com packages compartilhados:
├── apps/
│ ├── brand-a/ # Next.js app
│ ├── brand-b/ # Astro app
│ └── brand-c/ # Next.js app
├── packages/
│ ├── ui/ # Shared component library
│ ├── cms-client/ # Shared CMS integration
│ ├── analytics/ # Shared analytics wrapper
│ └── config/ # Shared TypeScript/ESLint config
├── turbo.json
└── package.json
// turbo.json
{
"pipeline": {
"build": {
"dependsOn": ["^build"],
"outputs": [".next/**", "dist/**"]
},
"deploy": {
"dependsOn": ["build"]
}
}
}
Turborepo (ou Nx) lida com o grafo de dependências para que você reconstrua apenas o que mudou. Brand A recebe uma nova feature? Apenas brand A reconstrói e faz deploy. Package de UI compartilhado recebe atualização? Tudo que depende dele reconstrói.
O Híbrido: Multi-Tenant CMS, Multi-Site Frontend
Esse é honestamente meu padrão favorito para a maioria dos cenários. Você consegue gerenciamento centralizado de conteúdo com deployments de frontend independentes:
┌─────────────────────┐
│ Headless CMS │
│ (Sanity/Contentful)│
│ Multi-tenant │
│ content spaces │
└──────┬──────┬───────┘
│ │
┌───┘ └───┐
▼ ▼
┌──────┐ ┌──────┐
│Site A│ │Site B│
│Next.js│ │Astro │
└──────┘ └──────┘
Editores de conteúdo conseguem um login e podem gerenciar todas as propriedades. Desenvolvedores conseguem codebases independentes e pipelines de deployment. É o melhor dos dois mundos para times que têm orçamento para isso.
Considerações de CMS
Sua escolha de CMS significativamente constrange -- ou habilita -- sua decisão de arquitetura.
Suporte a CMS Multi-Tenant
| CMS | Modelo Multi-Tenant | Suporte Multi-Site | Impacto de Preço |
|---|---|---|---|
| Sanity | Datasets por tenant | Excelente (múltiplos datasets em um projeto) | Tier free: 2 datasets; pago a partir de $99/mês |
| Contentful | Spaces por tenant | Bom (gerenciamento em nível de organização) | Cada space conta para o plano; $300+/mês |
| Strapi | Banco de dados único, filtrado por tenant | Implementação manual necessária | Self-hosted, escala com infraestrutura |
| Hygraph | Environments e stages | Federação de conteúdo multi-site nativa | A partir de $199/mês para planos de time |
| WordPress (headless) | WordPress Multisite | Maduro mas complexo | Custos de hosting escalam por site |
| Payload CMS | Multi-tenancy em nível de collection | Suporte crescente (v3.0+) | Self-hosted, open source |
O modelo de dataset do Sanity é particularmente elegante para setups multi-tenant. Cada tenant recebe seu próprio dataset com seu próprio schema, mas vivem sob um projeto. Você pode compartilhar definições de schema entre datasets enquanto permite customizações específicas de tenant. Em escala (10+ tenants), isso mantém suas operações de conteúdo sãs.
A abordagem de spaces separados do Contentful funciona mas fica cara rápido. Cada space em um plano de Team custa dinheiro real, e você está procurando por $300/mês mínimo antes de começar a adicionar spaces.
Implicações na Modelagem de Conteúdo
Com multi-tenant, seu modelo de conteúdo precisa acomodar todos os tenants. Isso geralmente significa:
- Um campo
tenantoubrandem cada tipo de conteúdo - Regras de validação específicas de tenant
- Modelagem cuidadosa de permissões para que editores só vejam conteúdo de seu tenant
- Conteúdo compartilhado (como "configurações globais") que precisa ter escopo de tenant
Com multi-site, cada site tem seu próprio modelo de conteúdo. Mais simples por site, mas você perde a habilidade de compartilhar conteúdo entre sites sem uma camada adicional de sindicação de conteúdo.
Performance e Escalabilidade
Características de Performance Multi-Tenant
O maior risco com multi-tenant é o problema do "vizinho barulhento". Se tenant A executar uma campanha viral e traffic dispare 10x, todos os tenants sentem. Estratégias de mitigação:
- Edge caching por tenant: Use edge network do Vercel ou Cloudflare com cache keys que incluem o identificador de tenant
- ISR com revalidação consciente de tenant: Apenas revalide as páginas para o tenant cujo conteúdo mudou
- Rate limiting por tenant: Proteja recursos compartilhados de qualquer tenant único sobrecarregando-os
// next.config.js - ISR with tenant-aware revalidation
export async function generateStaticParams() {
const tenants = await getAllTenants();
const paths = [];
for (const tenant of tenants) {
const pages = await getTenantPages(tenant.id);
paths.push(...pages.map(page => ({
tenant: tenant.slug,
slug: page.slug,
})));
}
return paths;
}
Características de Performance Multi-Site
Cada site escala independentemente. Essa é a boa notícia. A má notícia é que você está gerenciando N pipelines de deployment, N dashboards de monitoramento, e N conjuntos de orçamentos de performance. Com 20+ sites, overhead operacional se torna o gargalo, não performance de aplicação.
De benchmarks que rodei em 2025, aqui está aproximadamente o que esperar no Vercel:
| Métrica | Multi-Tenant (1 app, 10 tenants) | Multi-Site (10 apps) |
|---|---|---|
| Cold start (Edge) | 20-50ms | 20-50ms por site |
| Tempo de build | 8-15 min (todos tenants) | 2-4 min por site |
| Build incremental | 30-90s | 30-90s por site |
| Memória por instância | 256-512MB compartilhada | 256-512MB cada |
| Custo mensal Vercel (Pro) | ~$20 | ~$200 ($20 × 10) |
Essa diferença de custo é significativa. Multi-tenant em um único plano Vercel Pro a $20/mês vs. multi-site precisando de Enterprise ou organização criativa de projetos.
Análise de Custos
Vamos falar números reais para um portfólio de 10 sites durante 12 meses.
Estimativa de Custo Multi-Tenant
| Item de Linha | Custo Mensal | Custo Anual |
|---|---|---|
| Vercel Pro (1 projeto) | $20 | $240 |
| Sanity Team (1 projeto, 10 datasets) | $99 | $1.188 |
| Desenvolvimento (build inicial) | -- | $40.000-60.000 |
| Manutenção (ongoing) | $2.000 | $24.000 |
| Total Ano 1 | -- | $65.428-$85.428 |
Estimativa de Custo Multi-Site
| Item de Linha | Custo Mensal | Custo Anual |
|---|---|---|
| Vercel Pro (10 projetos) | $200 | $2.400 |
| Sanity Team (10 projetos) | $990 | $11.880 |
| Desenvolvimento (build inicial, packages compartilhados) | -- | $50.000-80.000 |
| Manutenção (ongoing, 10 sites) | $4.000 | $48.000 |
| Total Ano 1 | -- | $112.280-$142.280 |
Multi-tenant é aproximadamente 40-60% mais barato, primariamente por causa de menor burden de manutenção. Mas esses números viram se complexidade multi-tenant leva a mais bugs, desenvolvimento de features mais lento, ou uma migração dolorosa depois.
Quer uma estimativa mais precisa para sua situação específica? Quebramos custos de arquitetura em detalhe durante nosso processo de discovery.
Estratégias de Migração
Às vezes você começa com uma abordagem e precisa fazer switch. Aqui está como fazer isso sem queimar tudo.
Multi-Tenant → Multi-Site
Essa é a direção de migração mais comum. Sinais que você precisa:
- Código específico de tenant excede 30% do codebase
- Deployments são bloqueados por testes de regressão cross-tenant
- Times estão pisando nos pés um do outro
A estratégia:
- Extraia código compartilhado em packages primeiro (componentes de UI, utilities, cliente de CMS)
- Crie uma estrutura de monorepo ao redor da app existente
- Faça fork da app para o tenant mais divergente
- Gradualmente mova outros tenants para suas próprias apps
- Delete lógica de tenant-switching de cada app conforme se torna standalone
Multi-Site → Multi-Tenant
Menos comum mas acontece, geralmente quando uma companhia adquire múltiplas marcas e quer consolidar operações.
- Audite todos os sites para padrões compartilhados (você vai achar mais do que espera)
- Construa a biblioteca de componentes compartilhados das melhores implementações
- Crie a app multi-tenant com o site mais simples primeiro
- Migre sites um por vez, validando paridade a cada passo
- Descomissione apps individuais conforme tenants entram em produção
Ambas as migrações são disruptivas. Orçamento 3-6 meses e esforço significativo de testes. Isso é exatamente por que acertar a decisão inicial importa -- isso não é apenas uma escolha de arquitetura, é um compromisso.
Se você está enfrentando essa decisão e quer conversar com alguém que já fez isso, entre em contato com a gente.
FAQ
Qual é a diferença entre arquitetura multi-tenant e multi-site?
Multi-tenant usa uma instância de aplicação única para servir múltiplas marcas ou clientes, com isolamento de tenant tratado na camada de aplicação. Multi-site deployd instâncias de aplicação separadas para cada site, potencialmente compartilhando código através de um monorepo e bibliotecas de componentes. A distinção chave é se você está rodando uma aplicação ou muitas.
Posso usar um CMS multi-tenant com um frontend multi-site?
Absolutamente, e frequentemente é a melhor abordagem. Um CMS headless como Sanity com múltiplos datasets dá a você gerenciamento centralizado de conteúdo, enquanto deployments de frontend separados dão a cada site independência em termos de escolhas de tecnologia, cronogramas de deployment, e escalabilidade de performance. Esse padrão híbrido funciona especialmente bem quando seus sites compartilham estrutura de conteúdo mas precisam de experiências de usuário diferentes.
Como arquitetura multi-tenant afeta SEO?
Apps multi-tenant servem conteúdo diferente baseado no domínio ou subdomínio, que search engines tratam bem contanto que você implemente URLs canônicas apropriadas, metadata única por tenant, e sitemaps separados. O risco é duplicação acidental de conteúdo entre tenants -- tenha certeza que sua geração de sitemap e robots.txt são conscientes de tenant. De uma perspectiva de SEO, search engines não se importam se seus sites compartilham um codebase; eles se importam com o conteúdo e markup que recebem.
Multi-tenant é mais barato que multi-site?
Geralmente sim, frequentemente 40-60% mais barato em custos de hosting e manutenção. Você está pagando por um deployment, uma configuração de monitoramento, e um conjunto de infraestrutura. Porém, multi-tenant pode se tornar mais caro em tempo de desenvolvimento se seus tenants divergem significativamente, porque a complexidade de gerenciar lógica específica de tenant cresce não-linearmente. O break-even point depende de quão similares seus sites realmente são.
Qual abordagem é melhor para WordPress multisite headless?
WordPress Multisite é inerentemente multi-tenant -- uma instalação WordPress, múltiplos sites. Se você está usando WordPress como um CMS headless, o network de Multisite te dá gerenciamento centralizado de conteúdo. Seu frontend pode então ser tanto multi-tenant (uma app Next.js) ou multi-site (apps separadas por site do WordPress). Para a maioria dos projetos baseados em WordPress, eu recomendaria o híbrido: WordPress Multisite como CMS, deployments de frontend separados por site.
Como eu lidar com autenticação compartilhada em uma app multi-tenant?
Use um provedor de autenticação centralizado (Auth0, Clerk, ou NextAuth.js) com gerenciamento de sessão consciente de tenant. O auth token deve incluir o contexto de tenant, e seu middleware deveria validar que o usuário autenticado tem acesso ao tenant requerido. Row-level security no seu banco de dados (Supabase e Neon ambos suportam isso) adiciona uma segunda camada de proteção contra vazamento de dados cross-tenant.
Qual é o número máximo de tenants que uma app multi-tenant pode lidar?
Não há limite duro, mas limites práticos emergem em volta de tempos de build e complexidade operacional. Com Next.js ISR no Vercel, vi apps multi-tenant lidiarem efetivamente com 50+ tenants. Além de 100 tenants, você vai querer procurar por on-demand ISR em lugar de pre-gerar todas as páginas, e você vai precisar de estratégias de caching sofisticadas. Plataformas SaaS como Shopify efetivamente rodam milhares de tenants, mas eles investiram anos nessa infraestrutura.
Eu deveria usar um monorepo para arquitetura multi-site?
Quase sempre sim. Um monorepo com Turborepo ou Nx te dá os benefícios de code-sharing de multi-tenant (componentes compartilhados, utilities, configurações) com a independência de deployment de multi-site. A chave é manter packages compartilhados bem-definidos e versionados. Sem um monorepo, você termina com código copy-pasted entre repos que diverge imediatamente e se torna uma pesadelo de manutenção em alguns meses.