3.14 Multilocação e arquitetura SaaS

Visão geral e motivação

A multilocação (multi-tenancy) é a prática de rodar uma única instância do seu software para que ela atenda a muitos clientes separados ao mesmo tempo, mantendo logicamente apartados os dados e a configuração de cada cliente enquanto eles compartilham o mesmo código e, muitas vezes, a mesma infraestrutura. Cada cliente é um locatário (tenant). Essa única ideia é o motor econômico do software como serviço (SaaS), o modelo em que você vende acesso a uma aplicação em execução e não uma cópia para instalar. Quando mil locatários compartilham a mesma implantação, você corrige uma vez, escala um sistema e o custo marginal do próximo cliente se aproxima de zero. É por isso que um produto multilocatário bem construído pode atender uma startup de duas pessoas e uma empresa de cem mil usuários a partir da mesma base de código, e por que o modelo de locação que você escolhe molda suas margens, sua postura de segurança e sua carga operacional por anos.

Para grandes equipes as apostas vão além do custo. A multilocação põe um requisito rígido no centro da sua arquitetura: o locatário A nunca deve ver os dados do locatário B, jamais, sob qualquer bug, condição de corrida ou erro de configuração. Um único vazamento entre locatários pode acabar com uma empresa. Ao mesmo tempo, o ponto inteiro do compartilhamento é a eficiência, então toda decisão de design fica num espectro entre isolamento forte (mais seguro, mais caro) e compartilhamento denso (mais barato, mais arriscado). Acertar isso é a diferença entre um produto que escala com elegância e um que ou o leva à falência com infraestrutura ou o põe nas manchetes. Este capítulo se apoia na arquitetura na nuvem (capítulo 3.11), depende bastante da arquitetura de dados (capítulo 3.4) e da segurança na nuvem (capítulo 4.3) e se conecta à escalabilidade e à resiliência (capítulo 3.5) e à atribuição de custos (capítulo 9.4).

Empresas e governos elevam ainda mais a barra. Os compradores corporativos negociam garantias contratuais de dados, exigem isolamento dedicado para o seu nível e esperam que vocês os migrem entre ambientes sem indisponibilidade. Os governos acrescentam leis de residência de dados, separação guiada por classificação e a exigência frequente de que cada agência seja seu próprio locatário, com sua própria fronteira de auditoria. As decisões de locação aqui não são detalhes de implementação: são compromissos que vocês assumem com todo cliente que confia seus dados a vocês.

Princípios fundamentais

O isolamento é um espectro, não um interruptor. Os modelos silo, pool e bridge trocam eficiência por separação. Escolha por nível e por recurso, não uma vez para tudo.
O contexto do locatário é sagrado. Toda requisição, consulta, linha de log e trabalho em segundo plano deve carregar um identificador de locatário, e todo acesso a dados deve ser delimitado por ele.
O vazamento entre locatários é a falha que mais importa. Projete para que um único filtro ausente não possa expor os dados de outro locatário. Defesa em profundidade, não uma cláusula WHERE.
Vizinhos barulhentos são um problema de arquitetura. Sem cotas e equidade, um locatário pesado degrada todos. Planeje antes que aconteça.
A configuração por locatário escala. O código por locatário não. Molde o produto com dados e sinalizadores, não com forks.
O ciclo de vida do locatário é uma funcionalidade do produto. A integração, o provisionamento, a saída e a exportação de dados devem ser de primeira classe, automatizados e auditáveis.
Você não gerencia o que não consegue atribuir. A observabilidade e o custo devem ser fatiados por locatário, ou você voa às cegas tanto na confiabilidade quanto na margem.

Recomendações

Escolha um modelo de locação por nível, ao longo do espectro de isolamento versus eficiência

Três modelos ancoram o espectro. No modelo silo (dedicado), cada locatário recebe sua própria pilha isolada: computação separada, banco de dados separado, às vezes uma conta ou rede separada. O isolamento é o mais forte e o raio de impacto de um bug é um locatário, mas vocês pagam por capacidade ociosa por cliente e operam muitas cópias. No modelo pool (compartilhado), todos os locatários dividem a mesma computação e o mesmo banco de dados, separados apenas pela lógica e por um identificador de locatário. A eficiência é a mais alta e o custo marginal de um locatário é quase zero, mas o isolamento passa a depender inteiramente de o seu código estar correto. O modelo bridge (híbrido) mistura os dois: computação compartilhada com bancos de dados por locatário, ou um pool compartilhado para locatários pequenos e silos dedicados para os grandes ou regulados.

Não escolham um modelo para o produto inteiro. A resposta certa costuma ser um bridge que mapeia para os seus níveis de preço. Ponham a longa cauda de pequenos locatários num pool compartilhado eficiente, onde a economia deles funciona. Ofereçam uma implantação dedicada ou de locatário único como nível premium para clientes corporativos que pagarão pelo isolamento e pelas garantias contratuais. Escrevam o mapeamento como um registro de decisão de arquitetura (capítulo 3.11), porque “quais locatários compartilham o quê” é uma afirmação de que as suas equipes de segurança, vendas e finanças dependem.

Particione os dados deliberadamente e torne impossível esquecer o escopo do locatário

Os dados são onde a multilocação vive ou morre, então tratem a escolha de particionamento como decisão central de arquitetura de dados (capítulo 3.4). Três estratégias acompanham os modelos de locação. O banco de dados separado por locatário dá o isolamento mais forte, cópia e restauração fáceis por locatário e exportação simples de dados, ao custo de muitos bancos para operar e de migrações de esquema para disseminar. O esquema separado por locatário dentro de um banco compartilhado é um caminho intermediário: um servidor, separação lógica, ainda muitos objetos para migrar. As tabelas compartilhadas com chave por coluna de locatário, em que cada linha carrega um tenant_id, são as mais densas e baratas e as mais perigosas, porque agora uma única consulta sem o filtro de locatário vaza dados entre clientes.

Se vocês compartilham tabelas, não dependam de os desenvolvedores se lembrarem do filtro. Imponham o escopo do locatário numa camada que não possa ser contornada: a segurança em nível de linha do banco de dados, que anexa um predicado obrigatório a toda consulta com base no locatário da sessão, uma camada de ORM ou de acesso a dados que injeta a cláusula do locatário automaticamente, ou ambas. Cinto e suspensório é o correto aqui. À medida que os locatários crescem, o sharding por locatário se torna natural: ponham grupos de locatários em shards de banco diferentes para que nenhuma instância isolada guarde todo mundo, o que também limita o raio de impacto da falha de um shard e permite mover um locatário grande para seu próprio shard sem mudar o modelo.

Propague o contexto do locatário por toda parte e defenda-se em profundidade contra vazamentos entre locatários

O identificador do locatário deve acompanhar toda unidade de trabalho. Estabeleçam-no na borda, normalmente a partir da sessão autenticada ou de um subdomínio, validem-no e passem-no pelo contexto da requisição, por toda chamada de serviço a jusante, toda sessão de banco de dados, todo trabalho enfileirado e toda linha de log e métrica. As lacunas perigosas são as assíncronas: um trabalhador em segundo plano que processa um trabalho sem restabelecer o contexto do locatário, um cache com chave sem o locatário, um tratador de webhook que confia num identificador de locatário vindo do chamador. Cada um é um caminho para servir os dados de um locatário a outro.

Tratem o isolamento entre locatários como propriedade de segurança com defesa em profundidade e entreguem os detalhes ao capítulo 4.3. Apliquem o princípio do menor privilégio para que mesmo um componente comprometido alcance apenas o locatário em nome do qual age. Nunca aceitem um identificador de locatário vindo de entrada controlada pelo cliente para decisões de autorização. Derivem-no da identidade autenticada. Nomeiem por locatário os espaços de nomes dos caches, os prefixos de armazenamento de objetos e os índices de busca para que uma colisão de chaves não atravesse a fronteira. Depois testem a fronteira de propósito: testes automatizados que afirmam que as credenciais do locatário A não conseguem ler os registros do locatário B e exercícios periódicos de red team que tentam escapar de um locatário. Um vazamento achado pela sua suíte de testes é um bug. Um vazamento achado por um cliente é uma crise.

Contenha os vizinhos barulhentos com cotas, limites de taxa e equidade

Quando os locatários compartilham recursos, o pico de um locatário vira a queda de todos. Esse problema do vizinho barulhento não é um caso de borda: é o comportamento padrão de um pool compartilhado sob carga. Projetem contra ele desde o início. Definam cotas por locatário nos recursos que importam (requisições por segundo, trabalhos concorrentes, armazenamento, custo de consultas) e imponham-nas com limitação de taxa na borda e nas fronteiras internas caras. Prefiram um escalonamento justo que dê a cada locatário uma parcela, em vez de filas por ordem de chegada que deixam um locatário matar de fome os demais.

Combinem a imposição com o seu modelo de locação. Num pool compartilhado, as cotas e a equidade são a defesa principal, então invistam nelas. Para um locatário cuja carga genuinamente excede o que o compartilhamento justo absorve, a resposta muitas vezes é promovê-lo para fora do pool, para uma implantação bridge ou silo, que é uma funcionalidade que vocês podem vender e não uma falha. Liguem isso ao seu trabalho de escalabilidade e resiliência (capítulo 3.5): o descarte de carga, os disjuntores e a contrapressão precisam todos ser sensíveis ao locatário, para que descartar o excesso de carga de um locatário proteja os outros em vez de degradar o sistema inteiro.

Configure os locatários com dados, não com forks do seu código

Todo cliente vai querer algo ligeiramente diferente: o logotipo, as regras de fluxo de trabalho, as integrações, um campo que vocês não têm. A maneira escalável de dizer sim é a configuração por locatário: sinalizadores de funcionalidade, configurações, direitos e pontos de extensibilidade que são dados, avaliados em tempo de execução e compartilhados por uma base de código. O caminho que destrói um negócio de SaaS é o código personalizado por locatário: um ramo, um fork ou um caso especial no caminho do código para um grande cliente. Com dez desses vocês já não têm um produto, têm dez produtos num sobretudo, e toda mudança precisa ser testada dez vezes.

Tracem uma linha firme. Modelem como configuração de primeira classe os eixos de variação que vocês aceitam suportar e tratem os pedidos fora desses eixos como roteiro de produto ou como um não firme. Quando um cliente precisa de personalização de verdade, deem a ele pontos de extensão (webhooks, uma API, plugins, campos personalizados) que rodem a lógica dele sem ramificar a de vocês. Reservem as implantações genuinamente sob medida para o nível premium de locatário único, onde o isolamento é o ponto e o preço mais alto cobre o custo operacional.

Torne o ciclo de vida do locatário automatizado, observável e com custo atribuído

Integrar um locatário deve ser um fluxo automatizado e de autoatendimento: provisionar a partição de dados do locatário, semear os padrões, definir os direitos e ficar pronto em segundos, não um chamado para uma equipe de operações. A saída importa tanto quanto e é mais fácil de negligenciar. Quando um locatário sai, vocês precisam conseguir exportar os dados dele num formato utilizável e depois excluí-los de forma comprovável, porque os contratos e a lei de privacidade exigirão as duas coisas. Projetem a exportação e a exclusão de dados desde o primeiro dia. Adaptá-las depois num esquema de tabelas compartilhadas é doloroso.

Instrumentem tudo por locatário. Marquem logs, rastros e métricas com o identificador do locatário para poder responder em segundos “esta queda é de todos os locatários ou de um?” e “qual locatário está conduzindo este custo?”. Atribuam o custo de infraestrutura aos locatários para saber sua margem real por cliente e identificar o locatário cujo uso o torna não lucrativo no preço atual (capítulo 9.4). A observabilidade sensível ao locatário e a atribuição de custo transformam a multilocação de uma caixa-preta em um sistema que vocês de fato conseguem operar e precificar.

Compromissos: prós e contras

Modelo de locação	Prós	Contras
Silo (pilha dedicada por locatário)	Isolamento mais forte, menor raio de impacto, conformidade e exportação fáceis por locatário, história simples de vizinho barulhento	Maior custo, capacidade ociosa por locatário, muitas cópias para operar e corrigir
Pool (totalmente compartilhado)	Menor custo marginal, empacotamento mais denso, um sistema para escalar e atualizar	O isolamento depende inteiramente da correção do código, pior risco de vizinho barulhento, exportação e exclusão por locatário mais difíceis
Bridge (híbrido, em níveis)	Eficiente para locatários pequenos, isolamento dedicado para os grandes, mapeia para os preços	Mais modelos para construir e operar, caminho de promoção entre níveis para manter
BD compartilhado, esquema compartilhado (coluna de locatário)	Armazenamento mais barato, uma migração, operação mais simples	Um único filtro ausente vaza dados. Precisa de segurança em nível de linha como apoio
BD compartilhado, esquema por locatário	Isolamento lógico, um servidor, boa exportação	Muitos objetos de esquema, migrações que se disseminam, limites de escala por servidor
Banco de dados por locatário	Forte isolamento de dados, cópia e exportação por locatário	Muitos bancos, disseminação de migrações, custo maior

A tensão central é isolamento versus eficiência, e ela atravessa todas as linhas. O compartilhamento mais denso multiplica as margens e multiplica o risco no mesmo movimento. O isolamento mais forte compra segurança e simplicidade a um custo real por locatário. A resolução não é escolher um polo, mas situar cada locatário deliberadamente no espectro, normalmente por nível: empacotar densamente os locatários pequenos onde a economia o exige e o risco é limitado, isolar os locatários grandes e regulados onde pagarão por isso e o raio de impacto precisa ser pequeno. Depois tornar seguro o lado denso com escopo de locatário imposto e tornar barato o lado isolado com automação, para que nenhum dos polos doa tanto quanto a versão ingênua.

Perguntas para discutir com sua equipe

Se um filtro de escopo de locatário estivesse ausente amanhã, um cliente veria os dados de outro cliente? Esta é a pergunta que separa um produto multilocatário defensável de um acidente à espera de acontecer. O teste honesto é rastrear um caminho de leitura real e perguntar o que impõe a fronteira do locatário: é uma cláusula WHERE escrita por um desenvolvedor, ou existe um apoio como a segurança em nível de linha do banco ou uma camada de acesso a dados que injeta o escopo aconteça o que acontecer? Levem seus caminhos reais de consulta, seus trabalhos em segundo plano e seus caches, porque o vazamento quase sempre se esconde no canto assíncrono que ninguém delimitou. Levem também os resultados de um teste que usa de propósito a sessão do locatário A para pedir os registros do locatário B e afirma uma negação. Se a fronteira repousa apenas na vigilância humana, vocês têm uma violação latente, e a correção (defesa em profundidade) deve saltar para o topo do backlog.
Qual modelo de locação e de particionamento de dados cada nível de cliente de fato usa, e ele corresponde ao que vendemos a eles? Muitas equipes derivam para um único modelo por padrão e depois descobrem que o preço e a arquitetura discordam: aos clientes corporativos foi prometido um isolamento que o pool compartilhado não dá, ou clientes pequenos estão em pilhas dedicadas caras que destroem a margem. Mapeiem cada nível ao seu modelo real (silo, pool ou bridge, banco por locatário, esquema ou tabela compartilhada) e ponham ao lado as garantias contratuais de dados que a equipe de vendas dá. Onde divergirem, vocês têm um risco de conformidade ou um problema de custo, e ambos valem ser trazidos à tona antes que um cliente ou um auditor os ache. A evidência a levar é o mapeamento de nível para modelo, o custo por locatário e o texto real dos contratos corporativos.
Quando a carga de um grande locatário dispara, quem mais sente, e qual é o nosso plano? Num pool compartilhado a resposta muitas vezes é “todo mundo”, e as equipes frequentemente não sabem disso até um incidente tornar óbvio. Percorram o que acontece quando o seu maior locatário faz uma importação em massa ou recebe uma onda de tráfego: as cotas por locatário e o escalonamento justo a contêm, o descarte de carga protege os vizinhos, ou o sistema inteiro degrada junto? Levem dados de carga e a história do último incidente de vizinho barulhento, porque o locatário que machuca vocês costuma ser um que vocês sabem nomear. A resposta deve moldar tanto o investimento em limitação de taxa quanto a estratégia de níveis, já que a correção mais limpa para um locatário que supera o compartilhamento justo é promovê-lo para uma implantação bridge ou dedicada pela qual vocês possam cobrar.
Quando um locatário sair amanhã, conseguimos entregar a ele uma exportação limpa e provar que excluímos todo vestígio, ou estaríamos na correria? A saída é a parte do ciclo de vida do locatário que as equipes negligenciam até que uma cláusula de saída de contrato ou um pedido da lei de privacidade force a questão, e a essa altura o esquema compartilhado torna dolorosas a extração e a exclusão. Para uma grande equipe o risco se agrava, porque os dados de um locatário estão espalhados pelo banco principal, caches, armazenamento de objetos, índices de busca, cópias de segurança e pipelines de análise, e cada um precisa ser exportado num formato utilizável e depois expurgado de forma comprovável. As considerações concorrentes são reais: as tabelas compartilhadas densas que dão armazenamento barato são exatamente as que tornam mais difíceis a extração e a exclusão por locatário, então a eficiência que vocês compraram na camada de armazenamento podem pagar de volta na saída. Levem um passo a passo ao vivo de uma saída num locatário real, a lista de todo repositório que guarda dados do locatário e a evidência que mostrariam de que a exclusão de fato aconteceu. Para locatários corporativos e governamentais, a exportação precisa ser certificada e a exclusão comprovável para satisfazer os estatutos de registros públicos e de privacidade, então tratem um caminho de exclusão ausente como um defeito de conformidade a fechar agora, não uma funcionalidade a acrescentar quando um cliente sair.
Quantos casos especiais pontuais para clientes individuais já vivem no nosso caminho de código, e onde está a linha que nos recusamos a cruzar? Os forks de código por locatário são o jeito silencioso de um negócio de SaaS deixar de ser um produto e virar muitos produtos sob um mesmo nome, onde toda mudança precisa ser testada contra todo caso especial e a velocidade decai à medida que se acrescentam clientes. A tensão é que um grande cliente com uma necessidade real é difícil de recusar, e um ramo no caminho do código parece mais rápido que construir uma superfície de configuração, então os casos especiais se acumulam uma exceção razoável de cada vez. Levem um inventário honesto: busquem na base de código por nomes de clientes e ramos específicos de nível, contem-nos e estimem o custo extra de teste e revisão que cada um impõe a uma mudança não relacionada. A discussão deve traçar uma linha firme entre a variação que vocês modelam como configuração de primeira classe (sinalizadores, direitos, pontos de extensão) e o trabalho genuinamente sob medida que vocês reservam a um nível premium de locatário único, onde o preço mais alto cobre o custo operacional. Para compradores corporativos que exigem personalização profunda, a resposta durável são pontos de extensão que rodam a lógica deles sem ramificar a de vocês, de modo que a governança e a auditoria continuem tratáveis em toda a frota.
Conseguimos dizer, por locatário, tanto o que um incidente está custando a quem quanto quais clientes são não lucrativos no preço atual? A multilocação vira uma caixa-preta no momento em que seus logs, rastros, métricas e custo de infraestrutura não carregam dimensão de locatário, porque então vocês não conseguem responder se uma queda é de um locatário ou da frota inteira, nem nomear o locatário cujo uso o torna um prejuízo no preço do contrato. Para uma grande equipe, essa atribuição é o que separa operar a plataforma de chutar sobre ela, e molda diretamente tanto a resposta de confiabilidade quanto o preço. As considerações puxam contra o custo de instrumentação e a cardinalidade: marcar tudo por locatário não é gratuito, e as métricas de alta cardinalidade pressionam o orçamento de observabilidade, então vocês escolhem deliberadamente o que fatiar por locatário e o que amostrar. Levem a cobertura atual de marcação por locatário, uma consulta real que atribui o gasto de nuvem a um único locatário e a tabela de margens que permitiria nomear o seu cliente menos lucrativo. Em contextos corporativos e governamentais, o custo por locatário e a observabilidade delimitada pela auditoria também alimentam o estorno de custos, o planejamento de capacidade e a fronteira de auditoria a que cada agência ou unidade de negócio tem direito, então a dimensão do locatário é uma exigência de governança tanto quanto operacional.

Perspectiva por setor

Startup. Entreguem um único pool compartilhado desde o primeiro dia e ponham sua escassa atenção de engenharia na única coisa que não pode ser adaptada depois: o escopo de locatário imposto. Um Postgres gerenciado com segurança em nível de linha, um tenant_id em toda tabela e o contexto do locatário resolvido na borda compram densidade segura sem uma equipe de operações. Não construam níveis silo nem infraestrutura por locatário de forma especulativa. Acrescentem um nível bridge só quando um prospecto corporativo pagante tornar o isolamento digno do seu custo.

Pequena empresa. Sem especialista em plataforma e com orçamento apertado, apoiem-se no que a sua nuvem e o seu framework já dão em vez de construir vocês mesmos a maquinaria de isolamento. Bancos de dados gerenciados com segurança em nível de linha, uma plataforma como serviço que delimita os locatários por vocês e um provedor de autenticação que carrega a identidade do locatário costumam ser mais baratos e mais seguros que equivalentes feitos à mão. Tratem a multilocação como decisão de comprar versus construir em cada camada e reservem o trabalho sob medida para os testes da fronteira do locatário que só vocês podem escrever.

Grande empresa. O problema é a governança do portfólio entre muitas equipes: uma arquitetura bridge em níveis, um registro de decisão de arquitetura mapeando cada nível ao seu modelo de locação e de particionamento de dados e atribuição de custo por locatário para que as finanças saibam a margem real de cada conta. Padronizem a propagação do contexto do locatário e o apoio de escopo para que nenhuma equipe os reinvente, orcem explicitamente o isolamento e a automação do ciclo de vida e mantenham um caminho suportado e precificado para migrar um locatário entre níveis sem indisponibilidade à medida que ele cresce ou suas necessidades de conformidade mudam.

Governo. A contratação, a residência de dados e a responsabilização pública conduzem o modelo. Fixem os dados de cada agência em regiões no país com política como código, isolem em silos as cargas sensíveis ou de alta classificação em contas separadas com sua própria fronteira de auditoria e deem a cada agência sua própria integração de identidade, regras de retenção e trilha de auditoria, para que os auditores de uma agência nunca vejam a atividade de outra. A saída deve produzir uma exportação certificada e uma exclusão comprovável para satisfazer os estatutos de registros públicos e de privacidade, e as garantias de locação que vocês assinam devem ser as que a sua arquitetura de fato consegue cumprir.

Exemplos

Startup. Uma startup de quinze pessoas constrói seu produto como um único pool compartilhado desde o primeiro dia e faz bem. Todos os locatários dividem um banco Postgres gerenciado, com um tenant_id em toda tabela, a segurança em nível de linha impõe o predicado do locatário no banco para que um filtro esquecido não possa vazar, e a aplicação resolve o locatário a partir de um subdomínio na borda e o passa por toda requisição e trabalho em segundo plano. A integração é de autoatendimento: um novo cadastro provisiona sua linha de locatário, semeia os padrões e fica no ar em segundos. Dois engenheiros operam toda a plataforma porque há um sistema para operar. Quando o primeiro prospecto corporativo de verdade exige um banco de dados dedicado e uma garantia contratual de isolamento, eles acrescentam um nível bridge: a mesma base de código, mas esse locatário recebe seu próprio banco em seu próprio shard, vendido por um preço que cobre o custo.

Grande empresa. Um fornecedor de SaaS que atende grandes instituições financeiras opera uma arquitetura bridge em níveis. Milhares de clientes pequenos e médios vivem em pools compartilhados regionais, com sharding por locatário, e cotas e escalonamento justo mantêm os vizinhos barulhentos sob controle. Os clientes bancários de nível mais alto recebem implantações de locatário único em contas de nuvem isoladas, com bancos de dados dedicados, chaves de criptografia por locatário e garantias contratuais de residência de dados e de isolamento escritas no contrato-mestre. Uma capacidade da plataforma migra um locatário entre níveis sem indisponibilidade quando ele cresce ou suas necessidades de conformidade mudam. O custo de cada locatário é atribuído por marcação, de modo que as finanças sabem a margem real de cada conta, e a observabilidade marcada por locatário permite ao engenheiro de sobreaviso dizer em segundos se um alerta é de um locatário ou da frota inteira.

Governo. Um provedor nacional de plataforma hospeda muitas agências governamentais como locatários separados e trata o isolamento como exigência legal e não como preferência. A lei de residência de dados fixa os dados de cada agência em regiões no país, imposta por política como código que bloqueia qualquer recurso numa região não permitida (capítulo 3.11). A classificação conduz o modelo: as agências que lidam com material sensível recebem implantações totalmente isoladas em contas separadas, com sua própria fronteira de auditoria, enquanto as cargas de menor classificação dividem um pool governado. Cada agência é seu próprio locatário, com sua própria integração de identidade, suas próprias regras de retenção e exportação e uma trilha de auditoria delimitada à sua fronteira, para que os auditores de uma agência nunca vejam a atividade de outra. A saída produz uma exportação certificada de dados e uma exclusão comprovável, porque os registros estão sujeitos a estatutos de registros públicos e de privacidade.

Justificativa de negócio: motivações, ROI e TCO

O argumento de negócio central da multilocação é a margem. Um modelo de locatário único, em que se implanta uma cópia nova por cliente, faz o custo de infraestrutura e de operações crescer de forma aproximadamente linear com o número de clientes, e seus engenheiros passam os dias corrigindo muitas cópias. Um modelo multilocatário compartilhado quebra esse elo: vocês corrigem uma vez, escalam um sistema e empacotam os clientes densamente o bastante para que o custo marginal do próximo locatário se aproxime de zero. É isso que permite a um negócio de SaaS crescer a receita muito mais depressa que o custo, e é por isso que investidores e conselhos tratam uma arquitetura multilocatário limpa como um indicador de empresa escalável.

O retorno aparece em três lugares: alavancagem operacional (uma equipe opera a frota inteira), entrega mais rápida (uma correção chega a todos os locatários de uma vez, então a velocidade não decai à medida que se acrescentam clientes) e opcionalidade de preço (um plano compartilhado para a longa cauda e um plano isolado premium para as empresas, ambos a partir de uma base de código). Ponham isso contra os custos que vocês precisam financiar com honestidade: a engenharia para construir isolamento de locatário imposto, cotas, automação do ciclo de vida e observabilidade por locatário, mais a disciplina de manter intacta a fronteira. O custo de errar é assimétrico e severo, porque uma única violação de dados entre locatários pode disparar multas regulatórias, evasão em massa e dano de reputação que superam de longe a infraestrutura que vocês economizaram compartilhando. Enquadrem o caso para a liderança como margem e escalabilidade no lado bom e risco existencial no lado ruim. Ancorem o acordo de nível de serviço e as garantias contratuais de dados ao modelo de locação que vocês de fato conseguem entregar, porque uma promessa que a arquitetura não consegue cumprir é um passivo, não uma venda.

Antipadrões e armadilhas

Escopo de locatário por convenção. Depender de os desenvolvedores se lembrarem do filtro de locatário em toda consulta, sem apoio no nível do banco ou da camada de acesso a dados. Uma omissão é uma violação.
Confiar num identificador de locatário fornecido pelo cliente. Aceitar o locatário da entrada da requisição para a autorização em vez de derivá-lo da identidade autenticada, o que deixa um chamador pedir os dados de outra pessoa.
Trabalho em segundo plano sem escopo. Trabalhos, caches, webhooks e exportações que perdem o contexto do locatário porque alguém só delimitou o caminho síncrono da requisição.
Forks de código por locatário. Tratar como caso especial um grande cliente no caminho do código até se manter muitos produtos divergentes sob um nome e cada mudança custar dez vezes mais.
Nenhuma defesa contra vizinhos barulhentos. Operar um pool compartilhado sem cotas nem equidade por locatário, de modo que o primeiro locatário a disparar derruba todos.
A saída como reflexão tardia. Construir sem exportação de dados nem exclusão comprovável e depois falhar na cláusula de saída de um cliente ou num pedido da lei de privacidade porque o esquema compartilhado torna dolorosa a extração.
Voar às cegas por locatário. Logs, métricas e custo sem dimensão de locatário, de modo que vocês não sabem de quem é o incidente nem qual locatário não é lucrativo.

Modelo de maturidade

Nível 1, Iniciar: A multilocação é improvisada e reativa. A separação dos locatários repousa em filtros escritos à mão sem apoio, o modelo é único para todos, não há cotas, a integração é manual e logs e custo não carregam dimensão de locatário. A equipe fica sabendo do vizinho barulhento e do quase-vazamento por incidentes.
Nível 2, Desenvolver: Aparecem práticas básicas, mas inconsistentes entre as equipes. Um modelo de locação é escolhido e o contexto do locatário é propagado pelo caminho principal da requisição, um apoio no nível do banco ou da camada de acesso a dados impõe o escopo nas tabelas centrais e existem cotas básicas por locatário. A integração é parcialmente automatizada e os logs carregam um identificador de locatário, mas os caminhos em segundo plano, a exportação e a atribuição de custo variam de serviço para serviço e não estão escritos em lugar nenhum.
Nível 3, Padronizar: A abordagem de locação é documentada e imposta em toda a organização. A locação em níveis mapeia para os preços, com um pool compartilhado para locatários pequenos e implantações isoladas para os corporativos e regulados, o escopo do locatário é imposto em profundidade e testado de propósito, as cotas e o escalonamento justo contêm os vizinhos barulhentos, o ciclo de vida do locatário, incluindo a exportação e a exclusão comprovável, é automatizado e a observabilidade e o custo são fatiados por locatário. Toda equipe segue o mesmo padrão de locação e não o seu próprio.
Nível 4, Gerenciar: O parque de locação é medido e controlado em relação a linhas de base. O isolamento, a equidade, a latência e o custo por locatário são acompanhados como métricas com metas acordadas: a cobertura de testes entre locatários, as taxas de violação de cotas e de incidentes de vizinho barulhento, o tempo de integração e de saída e a margem por locatário são reportados contra linhas de base, e as decisões de promover um locatário entre níveis ou reprecificar um não lucrativo são tomadas com base nessa evidência e não em anedotas. A conformidade de residência e de classificação é monitorada continuamente, e o desvio do padrão dispara uma resposta documentada.
Nível 5, Orquestrar: A locação é continuamente melhorada e integrada em toda a organização. As fronteiras entre locatários são exercitadas por exercícios rotineiros de red team, os locatários se movem entre níveis sem indisponibilidade à medida que crescem ou suas necessidades de conformidade mudam, a margem por locatário alimenta o preço e o planejamento de capacidade e as regras de residência e de classificação são impostas por política e não por revisão. O modelo se adapta conforme a mistura de clientes e o quadro regulatório mudam, e as lições alimentam produto, segurança e finanças como um único ciclo.

Ideias para discussão

Onde cada um dos seus níveis de cliente fica hoje no espectro de isolamento versus eficiência, e algum nível está no modelo errado para as garantias que vocês venderam ou para a margem de que precisam?
Se vocês tivessem de provar a um auditor que o locatário A não consegue acessar os dados do locatário B, que evidência poderiam produzir agora, e quanto dela é automatizada versus afirmada?
Quais dos seus caminhos assíncronos (trabalhos, caches, webhooks, exportações, índices de busca) restabelecem o contexto do locatário, e quais apenas o herdam ou confiam no chamador?
Quando um locatário supera o compartilhamento justo, vocês têm um caminho de promoção suportado e precificado para uma implantação bridge ou dedicada, ou a resposta padrão é um incidente?
Vocês conseguem atribuir o custo de infraestrutura a locatários individuais bem o bastante para nomear o seu cliente menos lucrativo, e isso mudaria como vocês precificam?
Para um locatário governamental ou regulado, vocês conseguem impor a residência de dados e o isolamento guiado por classificação por política e fazer a saída com uma exportação certificada e uma exclusão comprovável?

Principais conclusões

A multilocação, uma instância atendendo a muitos locatários, é o motor econômico do SaaS: conduz as suas margens e põe o isolamento entre locatários no centro da sua arquitetura.
Trate o isolamento versus a eficiência como um espectro e organize-o em níveis: empacote os locatários pequenos num pool compartilhado eficiente e isole os grandes e regulados em implantações bridge ou silo pelas quais eles pagarão.
Nunca apoie o escopo do locatário num filtro escrito à mão. Imponha-o em profundidade com segurança em nível de linha ou uma camada de acesso a dados e teste a fronteira de propósito.
Propague o contexto do locatário por toda requisição, trabalho, cache e log e defenda os caminhos assíncronos onde os vazamentos se escondem.
Contenha os vizinhos barulhentos com cotas por locatário, limites de taxa e escalonamento justo e promova os locatários que superam o pool em vez de deixá-los degradá-lo.
Molde o produto com configuração por locatário, não com código por locatário, e faça do ciclo de vida do locatário, da observabilidade por locatário e da atribuição de custo itens de primeira classe.

Referências e leitura complementar

Tom Kwok, Thao Nguyen, and Linh Lam, A Software as a Service with Multi-tenancy Support for an Electronic Contract Management Application (IEEE International Conference on Services Computing)
Frederick Chong and Gianpaolo Carraro, Architecture Strategies for Catching the Long Tail (Microsoft)
Amazon Web Services, SaaS Lens, AWS Well-Architected Framework and SaaS Tenant Isolation Strategies
Microsoft, Multitenant SaaS architecture and patterns (Azure Architecture Centre)
Google Cloud, Architecture for Multi-tenant SaaS Applications
Cor-Paul Bezemer and Andy Zaidman, Multi-Tenant SaaS Applications: Maintenance Dream or Nightmare? (Proceedings of the Joint ERCIM Workshop on Software Evolution)
The Open Web Application Security Project, OWASP Application Security Verification Standard (access-control and multi-tenancy requirements)
Martin Kleppmann, Designing Data-Intensive Applications (partitioning, sharding, and data isolation)